Whatever happened to the in-progress AGS engine?

[Longcat]

Great. Still missing a dev.

PS. I want to note that I am in no way a member of the ScummVM team, anything I say should not be taken as a representation of the teams view.

Just my 2 cents from watching this from the sidelines.

[ikmspb]

Well, I wanted to say that potentially could help finishing the fuzzie's port, given I find free time.

The biggest piece still missing is what should be expected from such port. First of all, what would be the range of AGS versions support.

The problem here is also that AGS project itself is currently at crossroads (again) with no defined future.


PS.

It seems you are expecting a lot for free.

I do actually expect things magically resolve themselves, so I could have a break. But it is not happening

[Ender]

I do actually expect things magically resolve themselves, so I could have a break. But it is not happening ;)

Ah yes - perpetual optimism, I also suffer from that indictment.

I think the fact we are having a mostly civil and open discussion and sharing perspectives from that time is a good thing :)


One of my observations is that these large communities have a percentage of members that don't communicate well and come across as overtly blunt or aggressive - sometimes just due to a language barrier. My second observation is that some people are just @#$k$, such as those behind the more malicious stuff. Fair to say, that may have led to some of us unfairly judging the wider community - but it's a rift we can mend :)

[Raziel]

@Barky

Regarding the "special needs" from AGS games.

I think it should be a first goal (if we ever talk about having goals with this engine) to make the biggest pie chart of ports work (SDL1/2).

I'm not sure what special features there would be for certain platforms, but there should be some sort of "default" feature pool for all ports, maybe the different porters can (could?) enable extra features later on. (I certainly couldn't!)

(That saying solely because i'm using SDL1/2 for the AmigaOS4 port)

@ikmspb

Who knows, maybe fuzzie will be even back and help out or join her branch again, though i haven't heard from here for a long time (at least not on the forums).


@all

Please, could we make that happen?
Pretty please?
With a cherry or [insert your favourite treat here] on top?

[Barky]

Please, could we make that happen?
Pretty please?
With a cherry or [insert your favourite treat here] on top?

Just a heads up that we're discussing it on the AGS forums.

http://www.adventuregamestudio.co.uk/fo ... opic=55631

You'll see that questions about some of the technical capabilities of ScummVM feature pretty prominently in the discussion, and that we're throwing around various models for how AGS could exist alongside/within ScummVM. Those are issues you might want to give your input on.

It would also be good to know: if the AGS community is positive and AGS devs want to work on it, is anyone on the ScummVM side interested in getting involved as well? (If it depends on other factors, what are they?)

[digitall]

Just my 2 cents, but I think the point of any future ScummVM AGS engine should be to support existing games, similar to the SCI engine support, especially when the older versions of the AGS interpreter will not run on modern systems.

So the target for the ScummVM AGS engine at least initially would be stable support for the existing popular AGS games, starting with older popular titles.

My point is to distinguish that the project aim is to preserve the ability to play older games on modern operating systems without needing to emulate an older OS running a possibly buggy older interpreter binary.

The future of AGS is probably out of our scope... and that is a question for the AGS community, but if we added an engine to support earlier AGS version games (v1.0 - v3.5 IIRC), we would still need to test title by title to check for any corner cases and that engine would not constrain any future development of AGS.

[Barky]

Just my 2 cents, but I think the point of any future ScummVM AGS engine should be to support existing games, similar to the SCI engine support, especially when the older versions of the AGS interpreter will not run on modern systems.

So the target for the ScummVM AGS engine at least initially would be stable support for the existing popular AGS games, starting with older popular titles.

My point is to distinguish that the project aim is to preserve the ability to play older games on modern operating systems without needing to emulate an older OS running a possibly buggy older interpreter binary.

The future of AGS is probably out of our scope... and that is a question for the AGS community

Yup, I can definitely see that POV.

If ongoing AGS development were to become part of ScummVM, the scope of ScummVM would then necessarily have to change.

Another possibility might be that the two projects sit alongside each other: AGS would (after porting the current/legacy engine to ScummVM) branch the ScummVM core, creating a custom version more suited to our needs and priorities going forward. Since the two projects would share a lot of common code, we could try to apply updates from one to the other whenever possible.

if we added an engine to support earlier AGS version games (v1.0 - v3.5 IIRC), we would still need to test title by title to check for any corner cases

The latest version is 3.4.1.

More than 2500 AGS games have been released, to give a lowball number (the AGS Games database, far from complete, has somewhere around 2300); plus many others that have been circulated privately, e.g. betas that were sent out to testers for games that were never officially finished. Many exist in several different versions, often without any kind of version numbering. Some are hard (in some cases practically impossible) to find a copy of. Some have been withdrawn because they violate copyright, or were later remade as commercial releases, or because the creator was simply embarrassed by them.

There's no way you could actually test them all one-by-one (not to mention what to do about all the ones that were buggy on release, or where it's impossible to determine what the "correct" behavior is).

[ikmspb]

Well, I hope it is not implied that the port must flawlessly support every single game at once.

not to mention what to do about all the ones that were buggy on release, or where it's impossible to determine what the "correct" behavior is.

If it's still possible to run original executable, you could compare to how it runs the game. That's might be a tedious thing to do indeed.

The good thing about AGS is that we still have access to many old versions of the Editor. Which gives an opportunity to replicate certain scenarios and compare differences between versions. At least that is what I did to fix some incompatibilities in the past.

There is a also a tool that disassembles AGS scripts, converting them from byte-code to human readable list of operations, by rof0r on github, that may come handy in particular cases. (using them would require deep knowledge of how AGS script works though, or at least how ASM works, since they have similarities)

[Raziel]

Just to throw in a random note i stumbled over in the AGS thread.

2. Current runtime features

2.1) Changing display mode at runtime, by the game script command.
2.2) Make it work with Hardware-accelerated backend. Which are implemented by ScummVM btw, and how? Do they support accelerated rendering per-sprite, or just speed up final drawing/scaling on screen?
For instance, tinting and lighting are performed as custom shaders by Direct3D and OpenGL renderers. Can an engine use shaders in ScummVM?

I'm not an official spokesperson, but i do think that 3D *games* are still out of scope of ScummVM, you may want to look at ResidualVM for those (sister project of ScummVM explicitely for 3D adventure games).

OpenGL has a limited use in ScummVM for e.g. (iirc) upcoming(?) hardware accelerated screen drawing? (Please correct me if i'm wrong)

[ikmspb]

I'm not an official spokesperson, but i do think that 3D *games* are still out of scope of ScummVM, you may want to look at ResidualVM for those (sister project of ScummVM explicitely for 3D adventure games).

OpenGL has a limited use in ScummVM for e.g. (iirc) upcoming(?) hardware accelerated screen drawing? (Please correct me if i'm wrong)

No, no, I was not speaking about 3D games. AGS is still purely 2D. What I meant there (probably was not clear enough) is this:

There are different ways to do same effect if you have software renderer and hardware-accelerated renderer like OpenGL. For example, tinting effect would have to be coded in C/C++ for software renderer, but may be shader with OpenGL. So the question is, whether we may/need to code everything in software mode regardless of backends.

Or, in a more broad perspective, my question was this: does your HA support assumes that separate sprites are rendered using hardware accelerated functions (so that you may have e.g. fast scaling and rotation applied, as well as shaders for individual sprites), or it is only final game image that is drawn as a texture?

But I have a concern that we could deviate this thread with advanced technical questions, so I am not assuming to have an answer right here.

[Raziel]

But I have a concern that we could deviate this thread with advanced technical questions, so I am not assuming to have an answer right here.

Me neither
Probably best for me to leave that to the ScummVM devs.

I'll keep an eye on this spot....

[Serious Callers Only]

I think that even a 'game preservation project' that tries to maintain compatibility with older titles and lets AGS++ just cut off the cruft would benefit from runtime patches that work around uses of the more problematic apis in older games.


For example, a while ago, i reported to AGS that 'Donna Avenger of Blood' because of a string returning " " instead of "" and the game testing against " ". Then the engine was fixed and... presto, workaround for games version inferior to X.Y.
I suspect a AGS perservation engine will be full of these workarounds unless the problematic games are identified and patched themselves. I'd think a engine mechanism to 'taint' apis on certain ranges of the engine version the game was made to identify/report problematic games instead of hardcoding old behavior could have potential to evolve engines, with a lot more work ofc.

Or maybe i'm exaggerating the maintenance burden and don't know what i'm writing about. *shrug*


edit: i was corrected it supports the feature, but at least some devs still complain about patches being 'huge' (and breaking savegames often). Maybe they just don't know how to create them easily?

[s]There is also a feature that AGS doesn't have (AFAIK) that 'even' SCI does which would be a damn good idea for patching (probably more something for AGS++): virtual filesystem that can replace files inside of the game archives without actually replacing the whole file (ie: the 'override' folder in SCI and Infinity Engine). Probably with a 'nice' automatic way of creating the files on the override by comparing two versions of a game so the dev doesn't have to think too much.
[/s]

[GateKeeper]

More than 2500 AGS games have been released, to give a lowball number (the AGS Games database, far from complete, has somewhere around 2300); plus many others that have been circulated privately, e.g. betas that were sent out to testers for games that were never officially finished. Many exist in several different versions, often without any kind of version numbering. Some are hard (in some cases practically impossible) to find a copy of. Some have been withdrawn because they violate copyright, or were later remade as commercial releases, or because the creator was simply embarrassed by them.

There's no way you could actually test them all one-by-one (not to mention what to do about all the ones that were buggy on release, or where it's impossible to determine what the "correct" behavior is).

I really don't want to get involved in the argument, but as someone who uses ScummVM (and someone who once considered using AGS for game creation, but in the end decided to use other software) I just wanna say that there are far less than 2500 games that are actually even remotely interesting by far and large. Many AGS "games" even have descriptions like "I made this in two hours..." which alone indicates that it's not really worth anyone's while to even think about playing it. Of course some of the best games ever have been created with AGS, so there's a whole lot of variety out there.

I think most people would be satisfied if the best titles would be playable with ScummVM, at least to begin with.

But I would also like to point out that testing 2500 games is not at all impossible really. If one person tests one game per day, it would only take seven people to test all games within a year. This is hypothetical of course, but still it's doable. I would also assume that at least some game creators would be willing to test their own creations.

[Barky]

I really don't want to get involved in the argument, but as someone who uses ScummVM (and someone who once considered using AGS for game creation, but in the end decided to use other software) I just wanna say that there are far less than 2500 games that are actually even remotely interesting by far and large.

And every game currently supported by ScummVM is?

Many AGS "games" even have descriptions like "I made this in two hours..." which alone indicates that it's not really worth anyone's while to even think about playing it. Of course some of the best games ever have been created with AGS, so there's a whole lot of variety out there.

There's a good amount of chaff, but I'd say some 2/3 of the titles in the database are proper games, so that still leaves ~1500 worthwhile games to consider.

But I would also like to point out that testing 2500 games is not at all impossible really. If one person tests one game per day, it would only take seven people to test all games within a year. This is hypothetical of course, but still it's doable. I would also assume that at least some game creators would be willing to test their own creations.

Even if you had people willing to do that, one person cannot properly test an adventure game for corner-case bugs in one day. (And if any bugs are found, they certainly won't be able to determine whether they are game bugs, ScummVM bugs or bugs in the original AGS engine – which may be necessary to include because other games rely on them.)

I think most people would be satisfied if the best titles would be playable with ScummVM, at least to begin with.

Indeed. My point was not to write off AGS support, but to point out that the approach digitall was suggesting just isn't feasible. To the extent that this is "the ScummVM approach", it serves as an example of how things need to be approached differently when it comes to AGS.

If AGS is added to ScummVM, I think the goal should be to support the various versions of the AGS engine; and we must assume that if the engine is correctly supported, the games will work (if they don't, they were broken in the first place). Of course, testing various games is necessary to make sure of this and to find any bugs, but there's no reason to make "test every single AGS game" a goal for its own sake.

[ikmspb]

I have to frankly say, the more I read the discussion about old games support in these posts above, the less I understand what's the point of argument is, because it looks like continous nitpicking in other people's replies.

Obviously, there is no way to make sure every single game works without testing them all, but on the other hand is this even required to launch the first version of the port? I've always seen it like this: you make support for particular range of engine versions, then you make fixes if someone finds an issue in specific game.

How to make sure the version is supported? I see two approaches here: either choose a number of games by their popularity, or choose a number of games to cover engine features (gfx operations, file operations, etc). Or mix these two approaches.


IDK if it's feasible to start with the very old game titles. The formats of the games between versions 1.0 - 2.5 are currently unknown. Unless Chris Jones still has got old engine sources and will be able/willing to pass them to developers, they will require reverse-engineering, which may take big amount of time. Meanwhile, the port itself is about maybe 80% completed, and theoretically supporting games in range of AGS 2.5* to 3.2 (we may copy missing compatibility fixes from our current engine). So, if it gets released with only that range of support, it will serve as a foundation for the further support updates.

Would that be okay for ScummVM (in a project sense)?