Created attachment 445618 [details, diff] Patch against dosbox-0.74_p20160629.ebuild Despite being unofficial, this patch is quite popular and was even included in the (Windows only) GOG release of Tomb Raider 1. I've tried it with this game and it works well. I hope to get it packaged. I don't yet know whether it'll work on non-x86 arches but I may try it on arm sometime. We'll therefore need to mask the glide flag on the other arches, at least initially. I'm also not fussed about this being stabilized so it could be added to package.use.stable.mask. Conditional patching isn't great but the patch doesn't allow the feature to be disabled at build time, only at runtime. Given its unofficial nature and the fact that it can only be used with relatively few games, most would prefer to not apply it at all. The patch originates from an old web forum post attachment that's been updated several times over the years. I didn't like the idea of adding that to SRC_URI so I've linked to a copy of the patch that I put in the openglide repository on GitHub instead. I don't want this patch to hold up new DOSBox releases so I'd be fine with initially dropping the flag on bumps when necessary. The patch still applies perfectly cleanly, despite last being updated about 4 years ago, so I guess it only touches parts of the code that rarely change. If it ever does fail to apply, I'm sure that between me, the Gentoo user who maintains openglide on GitHub, and the rest of the DOSBox community, we could figure it out. I could apply the changes myself so if nobody objects in the next couple of weeks, I'll go ahead.
Forgot to ask whether I should include this in 9999. I'm thinking perhaps not.
A couple of questions: What's your relationship to glide? If you are ultimately maintaining the patch through glide, Is it possible to add to the patch a configure flag so that adding the patch doesn't unconditionally add the support? Are there efforts to upstream the patch to dosbox? I know upstream isn't wild about releases, but they do have active development. Personally, I'd prefer to see the support be made conditional and configurable by the build system and then upstreamed. At that point, I'd be happy to add a new snapshot ebuild. Not sure if any of the other maintainers have other opinions on the matter though.
(In reply to James Le Cuirot from comment #1) > Forgot to ask whether I should include this in 9999. I'm thinking perhaps > not. If you're going to add it to releases, and it's not upstream, I think it should be in 9999. (In reply to NP-Hardass from comment #2) > If you are ultimately maintaining the patch through glide, Is it possible to > add to the patch a configure flag so that adding the patch doesn't > unconditionally add the support? +1 > Are there efforts to upstream the patch to dosbox? I know upstream isn't > wild about releases, but they do have active development. +1 (or link to upstream's thoughts on it, if it was already discussed) > Personally, I'd prefer to see the support be made conditional and > configurable by the build system and then upstreamed. At that point, I'd be > happy to add a new snapshot ebuild. Not sure if any of the other > maintainers have other opinions on the matter though. +1. I would be fine with adding a patch that could be disabled on build (and not necessarily waiting on upstream, though that's obviously preferred).
(In reply to NP-Hardass from comment #2) > What's your relationship to glide? The SourceForge project is dead. I found a fork on GitHub that had seen a few commits, most recently in February, so I submitted some further build improvements there and they were all accepted. Turns out the guy is a Gentoo user. As for why I want this, I wanted to show Tomb Raider 1 to my daughter so I grabbed it off GOG but was disappointed to find that it was only packaged for Windows, despite using DOSBox. I thought it would be cool to package this and when I realised they had added Glide emulation, I thought that would be fun to try too. I was impressed with the results. > If you are ultimately maintaining the patch through glide, Is it possible to > add to the patch a configure flag so that adding the patch doesn't > unconditionally add the support? I could look into it but if it isn't going to be merged upstream, there seems to be little point. > Are there efforts to upstream the patch to dosbox? I know upstream isn't > wild about releases, but they do have active development. My feeling was that this has been floating around for 9 years so if they were going to merge it, they would have done it by now. I tried to find out but they are yet to answer on SourceForge. I didn't manage to get an official answer on IRC either but one user (who claimed to be a nobody) said that it is because the patch is considered a little too experimental as it doesn't work with all games. The guy also pointed me to a newer alternative patch that doesn't depend on openglide. It's primarily targeted at Windows and I had some trouble getting it to build but with a little help, I finally got there. It seems quite sluggish by comparison though. Perhaps there's a reason but I didn't waste time on it. Between the performance and the build issues, the original patch seems like the winner, at least on Linux. > Not sure if any of the other > maintainers have other opinions on the matter though. I spoke to Mr Bones on IRC and he also thought that they would have merged it by now if they were going to.
I just wanted to follow up on this and see if the patch will be included (and I second that it should be available for dosbox-9999 as well). I also purchased the Tomb Raider collection from GoG and ended up discovering this patch. If there is any doubt about adding it to the DOSBox ebuild by default, perhaps make the patch optional via a USE flag? Wine and even the kernel sources have USE flags for experimental patches, so it wouldn't be unheard of.
(In reply to Patrick McMunn from comment #5) > I just wanted to follow up on this and see if the patch will be included > (and I second that it should be available for dosbox-9999 as well). I also > purchased the Tomb Raider collection from GoG and ended up discovering this > patch. If there is any doubt about adding it to the DOSBox ebuild by > default, perhaps make the patch optional via a USE flag? Wine and even the > kernel sources have USE flags for experimental patches, so it wouldn't be > unheard of. Thanks for the feedback. I certainly hadn't forgotten about this but got sidetracked with trying to package the game itself, which will ideally require EAPI work. That doesn't block this though so I've gone ahead and committed it. We were broadly in agreement when it was last discussed. I felt that 9999 should be left as vanilla since the patch may fail to apply but a default-disabled flag is what I originally proposed so I've added it anyway, after building and testing. Regarding the game, I never managed to get the music to work, which is unfortunate because it's very nice. I was going to take another look at that when I got back to packaging it. Please let me know if it works for you.
This patch no longer applies cleanly due to a change to "configure.ac" - I've opened #644176 for this.
