How to easily convert SCI patches to ScummVM?

[lwc]

With DOSBox being abandonware (and non of its variants reaching its mainstream status), many will probably join GOG sooner or later in embracing ScummVM.
All it takes is for a new Windows version to not support DOSBox and that's it.

[Kawa]

With DOSBox being abandonware (and non of its variants reaching its mainstream status), many will probably join GOG sooner or later in embracing ScummVM.
All it takes is for a new Windows version to not support DOSBox and that's it.

All I see here is predictions.

And again: no matter if you use ScummVM to run your SCI games or the original interpreters on DOSBox, plain ol' patch files still work the same. I should know, I just loaded up PQ2 in both options and my copy protection bypass kicked in both times with no complaints.

Edit: I looked into the blacklist thing. I can see three sound issues, one music issue, and one musician issue (and that one can be un-blacklisted with a checkbox). The NRS file patches are either disabled by internal SVM patches (speed throttle stuff that's not needed in SVM and may in fact cause more issues), outright baked in (Skate-O-Rama timing), or otherwise unrelated internal patches with alternate versions specifically made to work with NRS versions.

[lwc]

All I see here is predictions.

I think GOG switching to ScummVM means it's already happening and not just predictions.

In any case, a patch that will be released nowadays has no way to reach GOG, etc. The only chance it has for having more than 5 people using it is by being a ScummVM patch.

[Kawa]

Even if GOG switched to ScummVM, why insist on using ScummVM internal patches? And besides, that's just GOG. If you don't get your sierras from GOG, you decide if you want to play 'em on ScummVM, DOSBox, or an actual contemporary PC. Only reason you might not take the GOG version and run it on DOSBox or an actual old beige box is if they only include the resource files and leave out the interpreter and drivers since ScummVM doesn't need those.

"All it takes is for a new Windows version to not support DOSBox and that's it." do you realize how unlikely that is? The Windows devs wouldn't need to just drop the ball, they'd have to drop three dozen to break compatibility that hard. And DOSBox is not just available for Windows, let's not forgot, any more than ScummVM is.

Edit: the same can be said about ScummVM to be entirely honest. If you can't guarantee a future version of Windows will still be able to run DOSBox, you can't guarantee it'll still run ScummVM either.

Pros of internal ScummVM patches: they can be bound to specific versions of specific games via signatures.
Cons: every time you make one, you have to update ScummVM and all affected users have to download a whole new copy of ScummVM, because they're inherently a part of ScummVM.

Pros of external patch files: they're easy to make (just use SCI Companion and export the affected area), they can cover most any type of resource instead of only scripts, they're nice and small compared to the whole SVM.
Cons: you can't automatically match a given patch to a specific version of a specific game (kinda re like IPS vs BPS in that regard).




...I feel kinda inspired to add signature matching support to SCI11+ now. A special header (if the first byte's not & 0x80 it's not a valid raw patch) to state the target's game ID and the bytes to find, followed by the replacement.

Code: [Select]

11 2B ; "11+" header, as opposed to 83 00 for a text resource.
4B 51 35 00 00 00 00 00 ; KQ5
01 00 ; one block to replace
09 00 ; nine bytes of signature
11 00 ; seventeen bytes to replace
70 6F 69 73 6F 6E 6F 75 73 ; 'poisonous'
76 65 6E 6F 6D 6F 75 73 20 73 6E 61 6B 65 21 22 20 ; 'venomous snake!" ' with a padding space because we're keeping it simple.
Silly example considering KQ5 isn't SCI11 so my terp can't run it but it serves its purpose. If I didn't want to keep it simple I could add block types so the patch could move data around, like "copy 0x1D2 bytes from 0x79 to 0x78", so the replacement can be only eight bytes long.

[lskovlun]

Code: [Select]

70 6F 69 73 6F 6E 6F 75 73 ; 'poisonous'
76 65 6E 6F 6D 6F 75 73 20 73 6E 61 6B 65 21 22 20 ; 'venomous snake!" ' with a padding space because we're keeping it simple.


[lwc]

What an interesting debate.

And DOSBox is not just available for Windows, let's not forgot, any more than ScummVM is.

I doubt many vintage quest players don't use Windows.

Edit: the same can be said about ScummVM to be entirely honest. If you can't guarantee a future version of Windows will still be able to run DOSBox, you can't guarantee it'll still run ScummVM either.

I disagree with that. Unlike DOSBox, which already stopped releasing new versions almost half a decade ago, at least in the near if not distant future ScummVM developers will prepare a version to fit with new requirements or at least release it after they'll get blocked.

[Kawa]

Not much of a debate when neither party seems willing to give an inch.

But you know what? I think we've gotten distracted from the real question.

Why would you insist on distributing patches as specifically ScummVM patches?

• They only apply to the specific game and version they're meant for.
• They're only as big as they need to be.
• But not everyone can make them -- that means both putting the patch together and having it merged into the ScummVM repo.
• And they only apply if and only if you use ScummVM.
• And they only work for script resources.

Separate file patches though?

• Anyone with a copy of SCI Companion, SV, and/or a hex editor can make them.
• They work for most any type of SCI game resource -- pictures, views, scripts, text, music...
• They apply both in ScummVM and the original interpreters, on DOSBox and original contemporary MS-DOS machines.
• But you can mismatch them, applying them to the wrong game and/or version.
• And you have to replace the whole file even if it's a single byte changed.

Keep in mind, please, that you don't control what other people want to use to run these games, and can't possibly predict how things may or may not stop running in the future.




... and I know it seems hypocritical to try and get the conversation into focus and then saying this, but that's not even getting into fan games. A bunch of old SCI Studio era fan games are listed in the detection tables, but as far as I know the only SCI1.1 fan game in there is my own. And I can't exactly testify to a good experience trying to develop said game using ScummVM. A single hash mismatch and it utterly refuses to run! So personally, I'll stick to DOSBox, thanks. At least it lets me test my builds.

[Collector]

With DOSBox being abandonware (and non of its variants reaching its mainstream status), many will probably join GOG sooner or later in embracing ScummVM.
All it takes is for a new Windows version to not support DOSBox and that's it.

DOSBox is NOT abandonware. That is why the official DOSBox has not added the Munt patch into it. Peter does not want associate it with something that requires the MT-32 ROMs to work, given Roland claims the IP for them. For all of that, SVM at one time went through legal troubles from LA for piracy claims, while DOSBox has never had a challenge against it. To equate DOSBox with abandonware is ignorance at best.

To dismiss DOSBox as no longer being developed is silly. It is under constant development, even if there has been no new major release for the last few years. The last half dozen commits were within the last month or so. All you have to do to see the activity around DOSBox is to go to VOGONS. I would note that the sound of DOSBox is more accurate than SVM and the pixel perfect patch makes the graphics better with the right aspect correction.

The reason that SVM has had so many new releases is that it only supports games that have been added one by one. DOSBox will run almost any DOS game and most applications. This allows DOSBox to run many, many hundreds more games than SVM is able to. Plus there are forks that extend its capabilities, even installing Windows 9x in it.

Also, as Kawa notes, DOSBox is multi-platform and is available for almost everything that SVM is. I don't mean to attack you, but your views of the two have been formed with a lack of information. You may prefer SVM and that is fine, but you don't need to misrepresent the other option to justify your choice.

[lwc]

I think we can be more civil than that, as I do feel getting more and more attacked in this thread despite you not meaning to. You can just say you don't agree rather than calling me silly (or other constant name calling that were used in previous messages).
Just because there's a deep and passionate community around DOSBox doesn't mean fluent commits are the same as stable versions.
While they are the same for "insiders", most population doesn't look behind stable versions which is why for example Wikipedia first and foremost mentions the last stable date.

[Kawa]

No no, look again. Collector called dismissing DOSBox silly, not you.

[MusicallyInspired]

Just because there's a deep and passionate community around DOSBox doesn't mean fluent commits are the same as stable versions.
While they are the same for "insiders", most population doesn't look behind stable versions which is why for example Wikipedia first and foremost mentions the last stable date.

[citation needed]
(speaking of Wikipedia)

Also, it doesn't matter what version or flavour of DOSBox you use (and there are many that are under active development, btw, and always will be), SCI games will work on all of them (old or new).