Topic: AGS source refactoring

[Alan v.Drake]

I have set up a repository so we can start to refactor the engine code. Any developer willing to join is welcome to.

https://github.com/AlanDrake/Adventure-Game-Studio/tree/Refactoring


One of the top priorities is splitting up AC.CPP into smaller organized files, 30k lines of code just won't do.  
I have started analyzing the code, I hope to be able soon to organize functions into groups and then make classes of what necessary.

In the meanwhile, we should also discuss coding conventions, ScummVM's seem to be a good starting point.

Let's get to work!

EDIT: I wrote souce and nobody said anything ?!

- Alan

[dreammaster]

I have set up a repository so we can start to refactor the engine code. Any developer willing to join is welcome to.

...

In the meanwhile, we should also discuss coding conventions, ScummVM's seem to be a good starting point.

Particularly given that you're in favour of following the ScummVM code formatting guidelines, it may be worthwhile considering merging your effort with that of fuzzie, who's recently started a combination refactoring of the code and porting it to the ScummVM framework.

See  https://github.com/fuzzie/scummvm/commits/ags for the repository, and http://logs.scummvm.org/log.php?log=scummvm.log.12Feb2012&format=html around 14:15 where there's a brief discussion about it.

Given how much work I understand refactoring the source code at all will take, it seems worthwhile to merge efforts. I know there's a lot of talk in the AGS Source Code release thread recently that I haven't weighed in on, but there doesn't seem like any major issues that would prevent collaboration on cleaning up the code.

[fuzzie]

Particularly given that you're in favour of following the ScummVM code formatting guidelines, it may be worthwhile considering merging your effort with that of fuzzie, who's recently started a combination refactoring of the code and porting it to the ScummVM framework.

See  https://github.com/fuzzie/scummvm/commits/ags for the repository, and http://logs.scummvm.org/log.php?log=scummvm.log.12Feb2012&format=html around 14:15 where there's a brief discussion about it.

That discussion is with Alan v.Drake, in fact! As noted, I am not advocating the use of my code because it's the start of a fairly drastic rewrite of many parts of the runtime and that might well introduce too many new bugs (and cause problems for things like the editor), but am hopeful that it might (at some point) be a helpful reference to those refactoring.

[Alan v.Drake]

I hope you guys aren't expecting me to do all the work, I'm not a great C++ developer. I'd rather follow the lead of someone more experienced.
Step up so I can add you to the collaborators!

As fuzzie said, she's working on a complete rewrite, but sharing insight between the two parties will result in positive things for sure.


EDIT: What about JJS repo,  I had simply uploaded the original source from the svn, but if his one is better and works for all the platforms right off the bat, then I should start sweat on that instead...

- Alan

[Alan v.Drake]

EDIT: Double post

[fuzzie]

EDIT: What about JJS repo,  I had simply uploaded the original source from the svn, but if his one is better and works for all the platforms right off the bat, then I should start sweat on that instead...

I am certainly basing my refactoring on JJS's work - it has useful bugfixes, compatibility improvements, etc.

[timofonic]

Hello.

Someone said me Calinleafshade did a tool named AGSpull, it was able to extract information about the game like version and such. He cancelled and removed it because ethical reasons, he feeled it was wrong or something like that.

Now that things changed, maybe this tool can be useful again. It can be useful to identify the version interpreter of each game to "emulate" the features of that specific version and quirks of it.

Or ar least that information can be provided to the interested developers of the currenct or future AGS projects, because interpreters would benefit of that kind of detection.

Maybe isn't so difficult and other developers figured the same kind of information too.

Calin, what do you think? Would you provide that information for the goodwill of the community? Please

Regards.

[Iceboty V7000a]

Someone said me Calinleafshade did a tool named AGSpull, it was able to extract information about the game like version and such. He cancelled and removed it because ethical reasons, he feeled it was wrong or something like that.

Actually some of these information are already readily available to people. If you right click and check the properties of a game executable you can already check the version of the interpreter (under windows of course), so if the tool just retrieves the interpreter version of a game there shouldn't be any ethical problem. However, there may be other aspects of a game that its author may not want people to hack into, so what we need is to find out what information should we  retrieve and what should be avoided.

[JJS]

The game data contains a version number, so when the engine loads a file it can check the version and set compatibility options accordingly.

For reading the meta information stored in the exe file (what you can see in the file properties in Windows), I have platform independent C code in my repository (/PSP/launcher/pe.c). The ports use it to detect valid game files by only accepting exe files with "acwin.exe" as the "original name" and a version that is supported by the interpreter.

[fuzzie]

Indeed; there's really complete version information (target interpreter version, game data version, GUI data version, room data version, etc etc) available in the game data file anyway. I hadn't thought about poking at the resources - my ScummVM engine detection just jumps straight to "searching for the game data in the binary" if it can't find a game file with a version in it, since that way I get the game name too. :-)

Note that here's also various pieces of (unused) code/structures for earlier runtime versions in the source code - probably very helpful for backwards-compatibility work.

It would be ideal if someday there would be a list of "target" games to test against, and that there be at least one for each interpreter version, but indeed you can just look at which interpreter was bundled (even if it isn't clear, you can just compare with the archived versions) without even needing to poke at the data.

[timofonic]

Indeed; there's really complete version information (target interpreter version, game data version, GUI data version, room data version, etc etc) available in the game data file anyway. I hadn't thought about poking at the resources - my ScummVM engine detection just jumps straight to "searching for the game data in the binary" if it can't find a game file with a version in it, since that way I get the game name too. :-)

Note that here's also various pieces of (unused) code/structures for earlier runtime versions in the source code - probably very helpful for backwards-compatibility work.

It would be ideal if someday there would be a list of "target" games to test against, and that there be at least one for each interpreter version, but indeed you can just look at which interpreter was bundled (even if it isn't clear, you can just compare with the archived versions) without even needing to poke at the data.

I agree about that, it can be a nice idea to do.

Also, a test suite for each AGS version would be interesting to have. A small demo testing each feature of AGS for all the available versions could be nice to have for testing regressions and such too.

Maybe people that know AGS a lot more can help on this

[Calin Leafshade]

Well I did make a library to read game data but it read things like the games name and resolution, which would have been useful for Nimbus. It was basically just a C# implementation of Clib which is AGS's internal data packer.

It was never called "AGSPull" and I didn't not release it for ethical reasons. I didn't release it because it didnt work for all versions of Clib.

Kinda useless for this purpose though.