As long as AGS still actively developed I am rather reculant to include it in the official ScummVM source tree for the above mentioned reasons. Of course everyone is free to have its own fork of ScummVM.
It seems that AGS breaks functionality constantly, but games that are compiled with a certain interpreter would still run. This would put AGS in a similar position as SCI, which means we'd be able to support a subset of games until newer features are implemented.
In fact SCI is fundamentally different here. SCI is an engine which is not
actively developed anymore. Thus there is no upstream development ongoing, which we need to merge into our codebase. Seeing that SCI suffers from regressions quite often due to the fact that some slightly different handling is discovered in different engine versions, that makes me think that with AGS this would be a lot worse. Since AGS is steadily improved/worked on, thus aiming at supporting all
versions out there is even more work than with SCI.
maximus wrote:I don't necessarily see this as being a bad thing. It just means that ScummVM would likely be a version behind (once the "official" AGS engine is updated, we have to source and can implement changes).
Then again what's the point in having a ScummVM AGS engine, when you could just play the most recent AGS games with a up to date interpreter built from their open source base?
Having an AGS engine in ScummVM does not automatically mean it will run on all of our ports either. Some ports require memory alignment etc. which the AGS source code might neglect, endian issues, which newer AGS versions might not care about anymore, etc. Implementing this properly is a quite a bit of work and might change the engine source code in a fundamental way, which might make it harder to merge upstream changes. If someone worked on a ScummVM engine of AGS we might have more knowledge about that though.
Last but not least AGS might have different requirements on the graphics functionallity etc. which we do not support in ScummVM. I saw some D3D9 shaders in the AGS source after a quick look through it, I am not sure whether they are required or are just for special eye candy. But features like that would never be supported by a ScummVM AGS engine, at least not as hardware shaders, if it's done by a software implementation it might be.
Anyway to get some real knowledge about the AGS requirements and whether ScummVM fullfills those it would be required that someone tries to read himself into the AGS source code and/or tries to create some ScummVM engine out of it.
maximus wrote:If the engine is unlikely to be accepted though for the reason you indicated, then there's little incentive to do anything with this.
I don't want to say that there's no chance of an AGS engine getting accepted. But seeing that AGS is also different to all of the other engines we support, since it's actively developed, I am not sure how good the chances of it being accepted are.
Another point is would the original AGS author be fine with it? I know it's released under a open license, but actually I wouldn't feel good if we support it when the original author is strictly against it.