Topic: Initial AGS Engine Source Code release

[Pumaman]

Now that 3.2.1 has been released, AGS seems to be in a stable enough state to release the source code.

So, to that end I've added it to the SVN repository here:
https://svn.bigbluecup.com:7743/svn/ags/trunk
you will need the Common, NativeLibs and Engine folders within this.

I know there's been a lot of interest in this, so if you're a C++ programmer then the code is now available for your perusal. It's released under the Artistic License 2.0, as with the editor code.

You will need Visual C++ Express 2008 (this is a free download from MS). Do NOT use the 2010 version, this will probably not work and let's not complicate things at this stage by trying to use it.

In the VC++ Options, you'll need to add the /Common and /Common/libinclude folders to the VC++ Include Directories list.

You will also need to install the DirectX SDK from Microsoft if you don't already have it.

DO NOT use this source code as a learning resource or a guide on best practice.
The state of the source code is VERY BAD and should in fact be considered an example of BAD PRACTICE.
Unlike the AGS Editor code which is relatively modern and a generally good standard, the engine code dates back 12 years to 1999, and has a severe case of the another-bit-being-bolted-onto-the-side disease. It also retains compatibility with old versions which means that some of the old and particularly dire code paths cannot yet be removed.
So just to be clear, YES I KNOW that the code is in a bad state. You don't need to tell me that.
I also know that AGS is used by thousands of games with thousands of combinations of game settings and script functions, and that any attempt to refactor the code into a better state is likely to inadvertently break something in someone's game, which is why I haven't attempted to do it yet.

The first important question is, does it compile for you? I'm not 100% sure that I've uploaded everything it needs into SVN, so let me know.

If you're thinking about making a change to the engine, make sure you always consider:
* How does the change affect existing games? Will it break any backwards compatibility?
* Does the change work with all colour modes (8-bit, 16-bit, 32-bit)?
* Does it work with both "low-res" (320x200/320x240) and "hi-res" (640x400 upwards) co-ordinate systems?
* Does it work with both the DirectDraw and Direct3D graphics drivers?
* Is it cross-platform (ie. is there anything platform-specific that would break the Mac and Linux ports?)

If you're thinking about adding third-party libraries, remember that AGS must not use GPL libraries as the GPL license is too strict. Libraries licensed under the Lesser GPL (LGPL) are ok, however.
Always carefully read the license of any third-party libraries before proposing to use them in AGS.

[Kweepa]

It's asking for a username and password to access the subversion repositories.
But this is an awesome development!

[monkey_05_06]

Unless he's changed it, you should gain access with username "guest" and no password.

Oh, also: Sweet! Time to hone up on my C++ skillz.

[Calin Leafshade]

Would someone mind zipping it up and posting it somewhere for me?

My proxy server at work is mangling the svn http requests in transit.

Thanks gorgeouses.

[Sephiroth]

Just awesome! Thank you very much for sharing  :o

A quick link for Calin if you still need it.

LINK

[abstauber]

just amazing... who would have imagined that back in 99

Too bad I won't be able to contribute to the code, but I'll do my best to work on a modern hi-res template.

[Sslaxx]

Thanks for this, Chris!

Very initial thought: the headers on some of the files need to be altered to reflect the change of licensing.

[subspark]

Hey great work, Chris! A million thanks for doing this. 
Well this should be an interesting decade!

Cheers!

[Wyz]

The state of the code doesn't look that bad to me, I've seen worse.
I'm an experienced C/C++ programmer and as soon have time on my hand I'll dive right in. First stop: finding out how portable it is, I first might try to compile it with other compilers and see how much breaks. I know the plug-ins will break, but that will be the first step toward cross-platform compatibility.
Thanks for releasing it, and thanks for creating it in the first place. Much appreciated!

[Pumaman]

Very initial thought: the headers on some of the files need to be altered to reflect the change of licensing.

Good point, I need to update those.

First stop: finding out how portable it is, I first might try to compile it with other compilers and see how much breaks. I know the plug-ins will break, but that will be the first step toward cross-platform compatibility.

The codebase includes all the changes that were made to get the Mac and Linux ports working, so getting these to build should not be a big task.

The platform-specific code is in the ACPLXXX.CPP files, where ACPLWIN is the Windows port, ACPLLNX is the linux one and ACPLMAC is the mac port. However these may no longer build correctly with the latest 3.2.1 code, so may need some fixing up.

[Matti]

This is great news! I can't contribute anything but I'm totally looking forward to all the cool changes that will be made!

Well this should be an interesting decade!

Indeed!

[Calin Leafshade]

Is the compiler included in this release?

I assume thats included in the ags.native assembly but i dont see the code for it.

[tzachs]

This is super cool!
I'm not gonna touch the engine myself since I'm a spoiled c-sharper, so I'm gonna stick with the editor, but really excited to see what will people come up with.

[Greg Squire]

This is very awesome!  Thanks for opening this up Chris!  Looking forward to seeing what you all do to make AGS even more awesome.

[kingstone]

Wonderful news! Now let's get this ball rolling!

I'm having some problems compiling the engine in VC++ 2008. First off there is a reference to dinput.h which is not included. This can be fixed by installing the Direct X SDK and adding the SDK's /include/ folder to the VC++ include directories (just like /Common/ and /Common/libinclude/).

Then in almp3.c there are hard coded #include paths to mpg123.h and mpglib.h.
I tried changing these to just "mpg123.h" and "mpglib.h" so that they include files from the libinclude folder. This doesn't seem to be the right files though, because it generates a bunch of compile time errors:

[code]
------ Build started: Project: acwin, Configuration: DebugWorking Win32 ------
Compiling...
almp3.c
Y:\Dev\AGS\Common\libinclude\mpglib.h(22) : error C2079: 'fr' uses undefined struct 'frame'
Y:\Dev\AGS\Common\libinclude\mpglib.h(23) : error C2065: 'MAXFRAMESIZE' : undeclared identifier
Y:\Dev\AGS\Common\libinclude\mpglib.h(23) : error C2057: expected constant expression
Y:\Dev\AGS\Common\libinclude\mpglib.h(23) : error C2087: 'bsspace' : missing subscript
Y:\Dev\AGS\Common\libinclude\mpglib.h(24) : error C2061: syntax error : identifier 'real'
Y:\Dev\AGS\Common\libinclude\mpglib.h(28) : error C2061: syntax error : identifier 'synth_buffs'
Y:\Dev\AGS\Common\libinclude\mpglib.h(28) : error C2059: syntax error : ';'
Y:\Dev\AGS\Common\libinclude\mpglib.h(28) : error C3409: empty attribute block is not allowed
Y:\Dev\AGS\Common\libinclude\mpglib.h(28) : error C2143: syntax error : missing ']' before 'constant'
Y:\Dev\AGS\Common\libinclude\mpglib.h(30) : error C2059: syntax error : '}'
[and more]
[/code]

The hard coded paths reference a folder named /almp3_205/decode/ but I have been unable to google anything like that. How can I find the correct files to include?

Thanks a lot for releasing the source code CJ, I believe this will open up for lots of collaborative improvements ahead!

[Sephiroth]

You'll most probably need to install allegro to VC 2008, I'll update the post to let you know if I can compile.

[Pumaman]

Is the compiler included in this release?

I assume thats included in the ags.native assembly but i dont see the code for it.

No, the editor's Native assembly is not yet released. That will follow, but has further complications and it also cannot be compiled by the free Express versions of Visual Studio, which makes a source code release less useful.
Obviously though, to make any changes that need the game compiler to produce a different output, this will need to be modified so I will be providing the source in due course.

I'm having some problems compiling the engine in VC++ 2008. First off there is a reference to dinput.h which is not included. This can be fixed by installing the Direct X SDK and adding the SDK's /include/ folder to the VC++ include directories (just like /Common/ and /Common/libinclude/).

Ah thanks, I should have mentioned this. First post updated.

Then in almp3.c there are hard coded #include paths to mpg123.h and mpglib.h.
I tried changing these to just "mpg123.h" and "mpglib.h" so that they include files from the libinclude folder. This doesn't seem to be the right files though, because it generates a bunch of compile time errors:

Well spotted, I've checked in a fix for this so please try again with the latest version.

Basically the complication here is that AGS uses both ALMP3 (for MP3 playing) and APEG (for Theora video), but ALMP3 and APEG each use different versions of another library called MPGLIB. So AGS ends up having to include two different MPGLIBs, and has to manually direct ALMP3 to one of them and APEG to the other.

[dbuske]

I suggest that the code just be updated with c++ first, so there is a solid windows base.
Then when that is done then work on other ports.

[Electroshokker]

Sweet. I'll see if I can make a linux build of 3.2.1 soon.

Chris, are any parts of the source still closed?

I could release my linux Code::Blocks projects (with instructions) with your permission. (Can I release older versions of the engine or only the latest?)
I'm sure some of the more enthousiastic folks out there would love to start from a proper IDE setup, rather than starting with raw code.

Also, SVN will help a ton in re-integrating all the changes I made into AGS.

Anyways, great to see the engine going open source. That'll speed things up a notch or two. (I'd love to debate my usage of the Allegro 4.4 branch in Linux and the OpenGL integration, the last of which I haven't had any time for so far.)

EDIT:

Oh, and for your question: * Is it cross-platform (ie. is there anything platform-specific that would break the Mac and Linux ports?)

Hell yeah a bunch of stuff breaks for Linux... but I can help with that. I'd be happy to help any linux enthousiast to get it up and running.

[Shane 'ProgZmax' Stevens]

Very very nice, CJ.  I know how much you love AGS and want to protect it so people should consider this to be an exceptional olive leaf on your part and hopefully no one will make you regret it.

[kingstone]

Well spotted, I've checked in a fix for this so please try again with the latest version.

Good job, that solved it!

There's one more problem with the current revision, version.rc fails to #include "afxres.h". A few minutes of googling hinted that this is because afxres.h is an MFC include which does not come with VC++ 2008 Express.

I fixed the problem by exchanging:
[code]#include "afxres.h"[/code]
for:
[code]#define IDC_STATIC -1
#include <windows.h>[/code]

That's it, I now have a freshly compile acwin.exe that works perfectly! Thanks again!

[Joseph DiPerla]

Wow amazing! When I get back from Oregon, I will take a look at the code. This is awesome. I am learning c++ and c# currently and hopefully sometime in the future I can help with this project. Thanks CJ!

[perludus]

Alright! 

So if this could turn into an up to date Mac version, or better yet an embedded (via Flash?) web player for games, I would be in 7th heaven.

[Dave Gilbert]

Yay!

AGS has taken it's first eager steps into the wild. 

This is *extremely* exciting news, CJ.  Thanks for doing this.  I'm looking forward to seeing what happens next.

[Pumaman]

Thanks for all your positive feedback about this decision!

Chris, are any parts of the source still closed?

I could release my linux Code::Blocks projects (with instructions) with your permission. (Can I release older versions of the engine or only the latest?)
I'm sure some of the more enthousiastic folks out there would love to start from a proper IDE setup, rather than starting with raw code.

The only part of the source that is not yet released is the editor's Native DLL. Everything else is now in SVN.

Yes, please do release that -- would be really useful for other people trying to build in Linux. Could you upload it in a ZIP since I'm the only one that has permissions to check in to the trunk?

There's one more problem with the current revision, version.rc fails to #include "afxres.h". A few minutes of googling hinted that this is because afxres.h is an MFC include which does not come with VC++ 2008 Express.

Interesting, thanks. I'll check that fix into SVN.

[Sslaxx]

I'd suggest using something like CMake with the engine code could be useful. That'd handle dependencies and create project files for Visual Studio, standard Makefiles, Code::Blocks etc. It's in use with a few projects, such as Allegro, OGRE and OpenMW for three.

[sigbuserror]

Hi everyone! I got the code to compile to an exe, but now I am not sure how to test it with data. Is there a way to use the demo game resources without building the whole editor etc?

[Sslaxx]

If you can find a game compiled with AGS 3.2.1, you can run it using the compiled exe.

[Calin Leafshade]

ya, either run the compiled exe as an argument like:

acwin thegame.exe

or replace the acwin in your AGS editor folder and compile a new game.

[sigbuserror]

cool that works! strange that the editor doesn't spit out a data bundle at some point before merging with an exe.

[Edmundito]

Woohoo! This is awesome! I was able to compile my own version of ACWIN! I think there's a tear coming out of my eye...

I ran into into warnings and 1 error (in the release build) along the way that are easy to fix but I think they should be mentioned so we can start cleaning things up. Should I post about these things, though? Should we start a separate thread about building the engine source code?

[Sslaxx]

Woohoo! This is awesome! I was able to compile my own version of ACWIN! I think there's a tear coming out of my eye...

I ran into into warnings and 1 error (in the release build) along the way that are easy to fix but I think they should be mentioned so we can start cleaning things up. Should I post about these things, though? Should we start a separate thread about building the engine source code?

Post here for now, I'd say.

[Edmundito]

Just a few notes about what I've run into so far. I was able to make the three builds, there were just a few things that happened on the way there that should be mentioned:


As soon as you open the project in VSC++ Express you get a warning about the source control binding (the scc plugin is not part of the standard edition):

The source control provider associated with this solution could not be found. The projects will be treated as not under source control. Do you want to permanently remove the source control bindings from the projects?

I got these warnings in the Debug and Release builds:

Warning   1   warning C4018: '<' : signed/unsigned mismatch   wwnd.c   473
Warning   2   warning C4244: '=' : conversion from 'sample_t' to 'float', possible loss of data   itrender.c   484
Warning   3   warning C4244: '=' : conversion from 'sample_t' to 'float', possible loss of data   itrender.c   485
Warning   4   warning C4244: 'function' : conversion from 'float' to 'int', possible loss of data   itrender.c   2971
Warning   5   warning C4244: 'function' : conversion from 'float' to 'int', possible loss of data   trender.c   2974
Warning   6   warning C4244: '=' : conversion from 'long' to 'byte', possible loss of data   itread.c   244
Warning   7   warning C4244: '=' : conversion from 'long' to 'byte', possible loss of data   itread.c   253
Warning   8   warning C4005: 'int64_t' : macro redefinition   ogg.c   6
Warning   9   warning C4005: 'DISABLE_MPEG_AUDIO' : macro redefinition     mpg123.c   8
Warning   10   warning C4005: 'DISABLE_MPEG_AUDIO' : macro redefinition     mpeg1dec.c   1

Only in the Debug build:

Warning   11   warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library   acwin

In the NOMP3 Release Build I got 427 warnings :S. Mostly on POSIX stuff. Example:

Warning   17   warning C4996: 'write': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _write. See online help for details.   file.c   2975

I did get this build error when building the Release and NOMP3 Release version:

Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

It turns out that the post-build events settings in the project you got some copy commands specific to CJ's computer:

cmd /c copy e:\code\ags\acwin\release\acwin.exe e:\code\ags\agsedit\release
cmd /c copy e:\code\ags\acwin\release\acwin.exe E:\Code\ags\netedit\AGS.Editor\bin\Debug

Finally, what I did to add the common dirs to the project instead of adding it to the Visual Studio settings:
1. Go to Project -> Properties...
2. Select All Configurations in the top left drop down
3. Under the tree Configuration Properties -> C/C++ -> General -> Additional Include Directories add ..\Common and ..\Common\libinclude
4. These additions could be potentially checked in that way people don't have to do it manually.

[Kweepa]

I got these warnings in the Debug and Release builds:

It's not a good idea to fix these warnings as they are in library code. Any fixes will confuse diffs and get lost when the libraries are updated.

Only in the Debug build:

Warning   11   warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library   acwin

This can easily be removed by going to the project properties, Linker/Input/IgnoreSpecificLibrary and adding ,LIBCMT to the end.

Similarly, the /LTCG warning can be removed by going to Linker/Optimization/LinkTimeCodeGeneration and changing the property to Use Link Time Code Generation.

In my opinion, the first step to make this useful is to break the 28,015 line AC.cpp monstrosity into sensible chunks, by feature. At first blush, I'd say something like this list:

save game
scripting (still quite big)
events
mp3
allegro
recording and playback
editor communication (debugger)
sound
packfile
translation
blitting
resolution support
dirty rectangles
tinting, lighting
draw
room
cursor
region
quit?
drawingsurface
dialog
datetime
viewframe
string
dynamicsprite
overlay
gamefile (load/unload)
gameoptions
display
speech
raw* functions
object
character
maths
fli
theora
inventory
gui (perhaps by control: textbox listbox button etc)
hotspot
game_get* functions
system_* functions
parser
file
mouse
viewport
interaction
script exports
mainloop
config
main

That would make most of these files 300-1000 lines each, which is good for comprehension and collaboration. We'd want to push most of these into sub folder(s).

Unfortunately it's pretty much a one-man job.

[bero]

Hi,
Thanks for releasing the source! I'm trying to get it to build on Linux - and I've been mostly successful, it compiles and links fine now using CMake (http://cmake.org/).
I've tried to keep everything portable, so with any luck, you can also use this on any other platform. (But I've only tested it on Linux; others may or may not work).

A couple of problems before I start sending patches:

• A couple of headers are #include-d in all-lowercase, but they're in the filesystem in ALL-UPPERCASE or Mixed-Case. On Linux and most other OSes, filenames are case sensitive... Someone with the right permissions should
  cd Common
  svn mv Wgt2allg.h wgt2allg.h
  svn mv CSCOMP.H cscomp.h
  svn mv CSRUN.CPP csrun.cpp
  svn mv FMEM.H fmem.h
  svn mv FMEM.CPP fmem.cpp
  svn mv MOUSEW32.CPP mousew32.cpp
  svn mv libinclude/AASTR.H libinclude/aastr.h
  svn mv libinclude/AAUTIL.H libinclude/aautil.h
  svn mv libinclude/ALFONT.H libinclude/alfont.h
  svn mv libinclude/ALFONTdll.H libinclude/alfontdll.h
  svn mv libinclude/AASTR.H libinclude/aastr.h
  svn mv libinclude/ALOGG.H libinclude/alogg.h
  svn mv libinclude/ALOGGDLL.H libinclude/aloggdll.h
  svn mv libinclude/ALMP3.H libinclude/almp3.h
  svn mv libinclude/LIBCDA.H libinclude/libcda.h
  svn mv libinclude/ALDUMB.H libinclude/aldumb.h
  svn mv libinclude/DUMB.H libinclude/dumb.h
  svn mv libinclude/INTERNAL libinclude/internal
  svn mv libinclude/internal/ALDUMB.H libinclude/internal/aldumb.h
  cd ../../Engine
  svn mv AC.CPP ac.cpp
  svn mv ALOGG.C alogg.c
  svn mv libsrc/aastr-0.1.1/AASTR.H libsrc/aastr-0.1.1/aastr.h
  svn mv libsrc/aastr-0.1.1/AASTR.C libsrc/aastr-0.1.1/aastr.c
  svn mv libsrc/aastr-0.1.1/AAUTIL.H libsrc/aastr-0.1.1/aautil.h
  svn mv libsrc/aastr-0.1.1/AAUTIL.C libsrc/aastr-0.1.1/aautil.c
  svn commit
• There's a copy of the Allegro headers in the source (Common/libinclude/allegro) -- some of those files should be autogenerated by the Allegro build process instead of being included (e.g. alplatf.h says #define ALLEGRO_MSVC). I can see a couple of possible fixes there:
  
  • Use system wide allegro installation instead of including allegro
  • Package the allegro sources instead of prebuilt directories
  • Given alplatf.h seems to be the only misbehaved file, drop it and have a correct version generated by the AGS build process
  Not sure which (if any) is preferred by the AGS developers?
  
• Some files contain very Windows specific code (acwavi.cpp) - while it probably wouldn't be overly hard to replace acwavi.cpp with something using ffmpeg to do the same in a cross-platform way, I know there was a previous Linux port, so some code must already exist - before I start redoing it from scratch, is that code available somewhere?
• acwsetup.cpp is very Windows specific - I know there is an old Linux port using gtk 1.x, but given no current Linux system has gtk 1.x installed anymore, I'd propose rewriting it using Qt - that would also be cross-platform.
• It would be good to document where to find the external dependencies (libraries that aren't part of a standard Linux system, and not included in the source):
  
  • Alfont
  • libcda

I've successfully played King's Quest III Redux with my port.

A last request: Any chance for a release of the 2.x source code so we can get older games to run better on Linux?


In case anyone is interested: Here's a patch file with the changes I made: http://arklinux.org/~bero/ags-20110501-linux.patch. Simply apply the patch, then run "sh prepare.sh", "cmake .", "make -j8" and you should have a working ags (in Engine/ags).

If you don't want to apply patches, here's a ready-made source tarball:
http://arklinux.org/~bero/ags-20110501-linux.tar.xz

And for those who just want to play, here's the resulting (Linux 32-bit) binary, built on Ark Linux dockyard-devel, may or may not work with any other Linux: http://arklinux.org/~bero/ags-20110501-linux

Will try to build a native 64bit version next...

[bero]

With my Linux port, I'm running into a crash in KQ3 Redux when trying to take the Cat's hair.

Looking at the backtrace:

#0  0x08129732 in ?? ()
#1  0x0812a802 in ?? ()
#2  0x0812da30 in do_layer3 ()
#3  0x08130087 in decodeMP3 ()
#4  0x080e8594 in ?? ()
#5  0x080e93bb in almp3_poll_mp3 ()
#6  0x080dfdb4 in MYSTATICMP3::poll() ()
#7  0x080e003d in MYSTATICMP3::play() ()
#8  0x0808a273 in load_sound_from_path(int, int, bool) ()
#9  0x080b202c in PlaySoundEx(int, int) ()
#10 0x080ed701 in call_function(long, int, long*, int) ()
#11 0x080eeb23 in cc_run_code(ccInstance*, long) ()
#12 0x080ef431 in ccCallInstance(ccInstance*, char*, long, ...) ()
#13 0x0808dc2f in run_script_function_if_exist(ccInstance*, char*, int, int, int, int) ()
#14 0x0808de48 in run_text_script(ccInstance*, char*) ()
#15 0x0808d96e in post_script_cleanup() ()
#16 0x0808dd2f in run_script_function_if_exist(ccInstance*, char*, int, int, int, int) ()
#17 0x0808e025 in run_text_script_iparam(ccInstance*, char*, int) ()
#18 0x080922d8 in process_event(EventHappened*) ()
#19 0x08092df3 in processallevents(int, EventHappened*) ()
#20 0x08092e3b in update_events() ()
#21 0x080cd975 in mainloop(bool, IDriverDependantBitmap*, int, int) ()
#22 0x080cddc9 in main_game_loop() ()
#23 0x080d073f in initialize_start_and_play_game(int, char const*) ()
#24 0x080d368c in initialize_engine(int, char**) ()
#25 0x080d1944 in main ()

I guess it's becaue apeg and almp3 both have a (slightly different) copy of mpg123, using the exact same symbol names - probably this is an effect of apeg's layer3 stuff being called from almp3.

I think the best fix (for all platforms) would be to check where the files differ, fix any incompatibilities, and just use 1 copy (and preferrably, replace both copies with the much newer version from http://mpg123.org/ -- among other things, this version fixes major security bugs).

Is there any reason why there are the 2 virtually identical copies, other than not having enough time to fix an issue that hasn't caused major problems before (like not wanting to diverge too far from upstream apeg/almp3)? If so, given almp3 is no longer developed, can we fix it now?

Other than that, my idea would be to introduce some #define hacks to change overlapping symbol names...

[bero]

I guess it's becaue apeg and almp3 both have a (slightly different) copy of mpg123, using the exact same symbol names - probably this is an effect of apeg's layer3 stuff being called from almp3.

I've confirmed that this is indeed the problem, (quick)fixed it, and updated my Linux builds.
Patch for this issue at http://arklinux.org/~bero/ags-20110501-apeg-almp3-symbol-ambiguity.patch

[bero]

Has anyone else looked into getting this to work on 64bit platforms yet?

Here's a list of issues I've found so far:

• In Common/Clib32.cpp, the MultiFileLib/MultiFileLibNew structures use arrays of "long"s to determine file positions. However, since sizeof(long) == 8 and the longs are read as sizeof(long) bytes from a file created on a 32bit OS (I don't think we want to rebuild the data files to run on a different OS, I like doing "ags Kq3redux.exe" on Linux...), the offsets are read incorrectly.
  Proposed fix: use "int" (always 4 bytes), or even "uint32_t" (guaranteed forever to be 32 bit) instead of long.
  Downside: Limited to 32bit file (4GB) file size even on a 64bit platform -- not a big issue given AGS can split files anyway.
  Without the downside, I think this can't be fixed without a format update that either stores sizeof(long) for the platform the data files were built on, or uses uint64_t everywhere.
• Various parts of the code pass pointers as parameters to functions requesting an int. Given a pointer is 64bit and an int is 32bit, only half the pointer is passed - this can't work.
  Unfortunately the obvious fix (change "int" to "long" for those) is less obvious to do than it sounds, given the various "int" parameters are passed on to more functions taking int parameters, and longs do cast to int implicitly - easy to miss a use.
  I'm not sure what this is supposed to accomplish in the first place - e.g. the 2nd parameter to do_main_cycle() is an int, but the only valid use seems to be passing a pointer.
  I think the best solution would be having a proper variant type (this is what it seems to be used for -- the ints are typically cast back to short*, char* or int* depending on context), but in the mean time, is there any reason to not just use a void*? At least that shows what's being expected and has the correct size.
• serialize_new_interaction() tries to putw() and getw() pointers. Should probably just use fwrite/fread...

I have a patch that takes care of those at http://arklinux.org/~bero/ags-64bit.patch.
It compiles now, and goes a lot farther than an initial attempt (before noticing the "long" usage in Clib32.cpp) - but I must still be missing something (probably another attempt to read a "long" from the data files somewhere...):

# /usr/src/repos/ags/Engine/ags Kq3Redux.exe
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 3.21.1115
Speech sample file found and initialized.
Audio vox found and initialized.
Checking sound inits.
jack_client_new: deprecated
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
An internal error has occurred. Please note down the following information.
If the problem persists, post the details on the AGS Technical Forum.
(ACI version 3.21.1115)

Error: No global script in game; data load error


I've compiled a 32bit Linux version with the 64bit patch applied, and that one still works fine, so the patch at large works.


Edit: After looking a bit deeper, I found GameSetupStructBase is read directly from the file, but it has members that are pointers. Obviously on 64bit, those are of a different size - it'll need a workaround like the one that's already there for ALLEGRO_BIG_ENDIAN.
However, I'm not sure how this can work at all (even on 32bit), given we can't just load the value of a pointer from disk and expect it to point to anything useful. I'm probably overlooking some implementation detail.

[Electroshokker]

The only part of the source that is not yet released is the editor's Native DLL. Everything else is now in SVN.

Yes, please do release that -- would be really useful for other people trying to build in Linux. Could you upload it in a ZIP since I'm the only one that has permissions to check in to the trunk?

Ok. I'll PM you the link of the 272 & 312 project package, so you can review, and I'm not sure you want those released.

For the rest of you, here's some basic goodies:

Linux AGS Setup Utilities for 2.72 & 3.12 Source Code
Static libraries you can use to build AGS
Sources of the dependency libraries

The following libraries have to be compiled manually, after which the header files need to be put in the /include folder of the project, and the libraries in the /lib folder of the project.

# alogg library - patch: makefile changed so we get a static library #
description: use Ogg/Vorbis streams with Allegro

# almp3 library - patch: makefile changed so we get a static library #
description: use MP3 streams with Allegro

# alfont library 1.9.2 - patch: src files & makefile changed so we get a static library #
description: use fonts with Allegro

# libcda library 0.5 #
description: cd player functionality

The sources provided are (except for libcda) NOT the original sources found on the web. The makefiles were changed to create static libraries (.a), and for the alfont library the sources where also changed so it supports AGS.

Do not get updated versions of these libraries, unless Chris Jones tells you otherwise.

Next on my list to prep for public release:

- a working code::blocks project for AGS 3.2.1 with updated notes in the project

[Edmundito]

Thanks to the linux info, I decided to dive in and find out how far I could get in building an OS X version. I haven't looked too much into it, but I got as far as building these allegro libraries:

libaldat.a liballeggl.a libloadpng.a liballeg.a libjpgalleg.a liblogg.a

I followed the exact same process with cmake, and I had to make+install my own libogg and libvorbis as well.

Obviously I'm missing a few of the libraries from Elektroshokker's package:
libaldmb.a libalfont.a libalmp3.a libalogg.a libcda.a libdumb.a

As I looked inside the Makefiles of the source that you provided I noticed that it's all configured for linux and there's no easy mac option.

[sigbuserror]

Electroshokker, would I be able to get that package from you? The link above doesn't seem to work. I am trying to get Flash Alchemy to build the code and having a working make file would be a big deal. Obviously there could be a lot of issues with libs, but I think your work so far might help!

*EDIT*  Ooops by "link" i meant the link bero set out with his pre-patched linux code.

[bero]

[in reply to #40]

Hi,

I just tried to download it and the link does work for me.

http://arklinux.org/~bero/ags-20110501-linux.tar.xz

Maybe you have a version of tar that is too old to handle xz compression?
In case that's the problem, I've uploaded an identical file, recompressed with gz (much bigger, but more compatible with old systems). The contents of the file are the same.

http://arklinux.org/~bero/ags-20110501-linux.tar.gz

[bero]

Obviously I'm missing a few of the libraries from Elektroshokker's package:
libaldmb.a libalfont.a libalmp3.a libalogg.a libcda.a libdumb.a

The source to the bits you're missing can be found at
http://libdumb.sourcearchive.com/ (libaldmb.a, libdumb.a)
http://chernsha.sitesled.com/ (libalfont.a)
http://tjaden.strangesoft.net/libcda/ (libcda.a)
You shouldn't actually need libalmp3.a and libalogg.a, the files used to generate those are also in the Engine sources.

As I looked inside the Makefiles of the source that you provided I noticed that it's all configured for linux and there's no easy mac option.

Are you referring to Elektroshokker's build or mine? If mine, you're overlooking something - I even put if(APPLE) statements into CMakeLists.txt. (They're untested, but should work for the most part).

[Edmundito]

[bero]

Honestly, I'm only testing the waters with OSX and I'm not at all familiar with cmake and I'm super rusty with make and most of gcc.

I'm the opposite - I'm very familiar with cmake, make and gcc, but almost the only thing I know about OSX is what it has in common with Linux.

So, the problem with the rest of the allegro libraries (like alfont) is that they don't have a specific makefile configuration for OSX, so the best bet would be to either make something on cmake or write a custom make option for OSX.

Probably. Another thing you can try:
alfont is configured by default to build for DOS/Windows, and while it has a Linux option, it doesn't work out of the box.
I've fixed it with this patch:
http://arklinux.org/~bero/alfont-2.0.9-linux.patch
If you're lucky, that will fix it for you too, given OSX is much more similar to Linux than to DOS/Windows.

May or may not work...

I have a patch that gets ags to build on 64 bit platforms, but it doesn't work (see my post about 64bit support on this thread - I'm hoping to get some feedback there from people more familiar with the inner workings of ags). Adding -m32 for now is the right fix.

AL_CONST is supposed to be defined by Allegro (usually in alconfig.h).
Given AL_CONST should always be defined to const (the sole reason for the existance of AL_CONST is to support prehistoric compilers that don't know the "const" keyword - I don't think any of those have been around for at least a decade), just adding this should fix you up:

[code]
#ifndef AL_CONST
#define AL_CONST const
#endif
[/code]

[timofonic]

A bit offtopic and for historical reasons, here is an old topic about open sourcing AGS...

http://www.bigbluecup.com/yabb/index.php?topic=33101.0

Things evolve in a way sometimes we think to me impossible, right?

[Snarky]

So, that reminds me, more recently we also talked about somehow getting AGS and ScummVM to be compatible, and the big stumbling block seemed to be that the AGS engine wasn't open source. Now that it is, should we take up the discussion again? It would be great if AGS games could run on all the platforms ScummVM targets.

[Calin Leafshade]

From reading the scummvm forum discussion it seems like the idea has largely been abandoned.

The problem for scummvm is that they want a stable and *static* codebase to support. Since AGS is still kind of in development (with lots of versions to support) they are reluctant to add an interpreter for AGS unless they control the code base, essentially using scummvm as the runtime for AGS, entirely replacing the ags runtime.

Since obviously CJ is not happy with that idea there is something of an impasse and so it seems unlikely that this will happen for a long time.

[timofonic]

From reading the scummvm forum discussion it seems like the idea has largely been abandoned.

The problem for scummvm is that they want a stable and *static* codebase to support. Since AGS is still kind of in development (with lots of versions to support) they are reluctant to add an interpreter for AGS unless they control the code base, essentially using scummvm as the runtime for AGS, entirely replacing the ags runtime.

Since obviously CJ is not happy with that idea there is something of an impasse and so it seems unlikely that this will happen for a long time.

I'm not a developer at all, but I think your asumptions seem wrong. Here is my point of view about how the ScummVM project manages this, but I'm sure any ScummVM Team member would be able to explain it better than me.

Engine developers control their codebase as maintainers of that part. ScummVM is a big project composed of different game engines and backends, they are not an entity but a team with subteams. Look at the credits,  they are a lot of people...

http://www.scummvm.org/credits/

ScummVM is not a runtime, but a collection of them.

Also, there are different engines and the developers still work on them. Some engines already added to the master branch are constantly evolving to support more games of the same engine or improving due to different reasons (bugs, limitations, performance..). They follow a quite dynamic development model, they only have a short period of feature freeze and stabilizing the ports each 2-3 months but it's quite flexible too, depending on free time of developers (all of them are volunteers, with the exception og Google Summer of Code participants) and other reasons.

A good example is FreeSCI: They had an independent project and then the merge was debated. After different discussions, they merged and lots of code contributions to adapt it to the OSystem framework (the portable framework system of ScummVM) got done. Most of the original developers still contribute to the code and some new developers got into contribution shortly after. They are working to improve the SCI engine constantly, the support improved in a very substantial way after the original merging.

So the idea would be merging the engine to be part of the family, not replacing it. They want to avoid competing, their way is collaboring in the most transparent way. They want the original developers become part of the project and becoming part of the engine subteam.

Short answer: They want the merged engine to become the main one, not playing to catch the official one. They want the original developers to agree and collaborate on it in a symbiotic way, not competing to show who's the best or being a second citizen.

[Snarky]

Yeah, but I think most AGSers would prefer to remain a separate project, not merge completely. AGS isn't just some open source programming effort--in fact, up until recently it wasn't an open source project at all. The community and culture here isn't primarily oriented towards engine development.

Rewriting or porting the engine so it'd be compatible with the OSystem is one thing (though I'm unclear on how that would work with the respective licenses). Subsuming AGS under ScummVM and giving up its own independent identity is another.

[timofonic]

Yeah, but I think most AGSers would prefer to remain a separate project, not merge completely. AGS isn't just some open source programming effort--in fact, up until recently it wasn't an open source project at all. The community and culture here isn't primarily oriented towards engine development.

Rewriting or porting the engine so it'd be compatible with the OSystem is one thing (though I'm unclear on how that would work with the respective licenses). Subsuming AGS under ScummVM and giving up its own independent identity is another.

Well, everything is up to the community and Chris Jones himself. You are very right.

Why people is so afraid about losing identity in a borg style? That thing would't happen if things get done properly.

There's a big difference between the engine and the community. There's the AGS editor too

Think of the AGS runtime as the video player only. You need something to make the videos and of course a community to debate about how to make them or about how good/bad they are etc.

Anyway, I think this should be debated in a meritocratic way. Game and engine developers should express their opinions on this topic with strong argumentations.

I'm not a developer and not used AGS extensively, just expressing my humble thinkings to the rest and bumping the debating in a bit more deeper way. It's up to the community to think by themselves

I just want to be able to play AGS driven games on lots of different platforms and seeing it as a healty community project, so ideas from others could be added to this great project and Chris Jones can.be more of a leader and having more time for his personal stuff. His experience is highly appreciated for the future of the project, he can be the Linus Torvalds of AGS

About licenses: Artistic License 2.0 is compatible with GPL too.

http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licenses
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

[Alan v.Drake]

ScummVM is meant to play old junk, so a complete merge makes no sense, I'm pretty sure that once the old AGS engine is given closure they will be glad to integrate it, while we'll be messing around with the new AGS, after all they're going to be different, aren't they ? It's not like you people can't just go around cluttering ScummVM code with experimental engine modifications, maybe 6 years from now when it's done, who knows...


- Alan

[abstauber]

Yeah, I'd say integrate 2.72 into ScummVM and let the 3.x branch alone. Of course it won't as easy as I wish it would be.
But if people really wish to create a multi-multi platform game, they could simply use that old editor.

[Snarky]

Would it be possible to do it the other way around, that we integrate the bits of the ScummVM engine that lets it run on so many platforms with AGS?

[Scavenger]

Yeah, I'd say integrate 2.72 into ScummVM and let the 3.x branch alone. Of course it won't as easy as I wish it would be.
But if people really wish to create a multi-multi platform game, they could simply use that old editor.

I would also think this is a good idea. We have the 2.72 source, and it's not going to get worked on ever again. Porting 2.72 and below to ScummVM allows old games to be played again (How many times have we had trouble running the old DOS games?) while freeing the current engine from the backwards compatibility issues. Sure, some people's games might break (probably some games made between 3.0.0 and 3.2.1 and using the legacy code), but it's worth it for cleaner code and extensibility. AGS as it was fits the ScummVM bill perfectly. It's discontinued, the source is available, and it plays adventure games.

Maybe, sometime in the future, a long way off, new AGS might join ScummVM's engine ranks. But until then, being able to play the old games is enough, I think.

Would it be possible to do it the other way around, that we integrate the bits of the ScummVM engine that lets it run on so many platforms with AGS?

I think the reason why ScummVM is so portable is because it uses portable libraries and no OS specific code. There is no particular bit we can integrate into AGS, apart from maybe it's discipline, and there's no importable library for that

[Wyz]

Yeah, I'd say integrate 2.72 into ScummVM and let the 3.x branch alone.

Hear hear!

The 2.72 branch would suddenly have support again on modern systems, and let them sort that out.
But the 3.x branch is still very much in motion, and then we must ask ourselves: yes we want full portability, but what is faster: Coverting it to ScummVM or porting the existing codebase to as much platforms as we can?
It'd say the latter will be the best solution, also because converting AGS 3.x to ScummVM would be like trying to fit an elephant into a refrigerator. And remember that AGS already has a VM that works really well.

[Snarky]

I think the reason why ScummVM is so portable is because it uses portable libraries and no OS specific code. There is no particular bit we can integrate into AGS, apart from maybe it's discipline, and there's no importable library for that

I was thinking that ScummVM probably separates the game engine(s) from the "get it to run on this machine" engine (which like you say may primarily be a collection of libraries, though I'd guess there's a bit more to it than that) through some standard API, and that we could adopt that lower-level API for AGS since it has already been ported to so many platforms. The ScummVM documentation talks about frontends and backends, which seems to match my mental model of how it works.

Now, admittedly I haven't looked at either the ScummVM code or the AGS engine code, so simply using the ScummVM backend as the AGS backend may not make sense, but if we want to make our adventure game engine multiplatform, and ScummVM has a backend to run adventure game engines on many platforms, there might be some synergy there, no?

[Calin Leafshade]

if we want to make our adventure game engine multiplatform, and ScummVM has a backend to run adventure game engines on many platforms, there might be some synergy there, no?

Not really, no.

AGS is already pretty cross-platform. There isn't *that* much work to do. People have already managed to compile in linux (minus sound support) and most of the libraries used are cross-platform.

Going through the hassle of making ags use a different runtime when the current one is fine seems silly.

if scummvm supported ags 2.x then that would be a different matter.

[Snarky]

So there will be an Android port any day now, then?

[Wyz]

I actually looked into Android, but that is still a long shot. Allegro (the lib AGS mainly uses) does not yet support Android. iPhone however is very much doable in a reasonable time span right now I guess. I'd say the same for Windows CE but I haven't really looked into that.

[Kweepa]

ScummVM uses SDL as a back end rather than Allegro.
I think there's an argument to be made for switching to SDL, since it supports more platforms and has a livelier developer base.
Of course Allegro is intertwined pretty deeply inside the codebase, so it wouldn't be an overnight job.

[Joseph DiPerla]

Isn't there a wrapper for SDL for those who use Allegro? I could be wrong and it might not be of much help, but maybe a wrapper would be helpful.

[timofonic]

Lot's of chatting, typical of forums. Are there people already working on this? I'm curious about it...

ScummVM is meant to play old junk, so a complete merge makes no sense, I'm pretty sure that once the old AGS engine is given closure they will be glad to integrate it, while we'll be messing around with the new AGS, after all they're going to be different, aren't they ? It's not like you people can't just go around cluttering ScummVM code with experimental engine modifications, maybe 6 years from now when it's done, who knows...


- Alan

I consider very humilliating your way of thinking to ScummVM, undervaluing classic videogames that are still considered as the best games of the adventure genre. They aren't "old junk" at all, but software to be preservated and able to use it in modern platforms.

There are newer games supported in ScummVM, an example is the Broken Sword 2.5 authorized fangame.

The rest of stuff might be a lot better replied by a developer from both ScummVM and AGS projects.

It's funny that you say this, because AGS was originally developed to mimic the style of classic adventure games (mainly Sierra On-Line' SCI ones, I think). There's remakes of classic games using AGS too.

if we want to make our adventure game engine multiplatform, and ScummVM has a backend to run adventure game engines on many platforms, there might be some synergy there, no?

Not really, no.

AGS is already pretty cross-platform. There isn't *that* much work to do. People have already managed to compile in linux (minus sound support) and most of the libraries used are cross-platform.

Going through the hassle of making ags use a different runtime when the current one is fine seems silly.

if scummvm supported ags 2.x then that would be a different matter.

Well, really yes.

AGS is not so cross-platform. There is lots of much work to do, specially in embedded platforms and alternative ones. People have already managed to compile in Linux (minus sound support), most of the libraries used are cross-platform but not so much ones supported. Also, the AGS runtime needs a deep cleanup too.

It's funny to hack your messages

[Kweepa]

Lot's of chatting, typical of forums. Are there people already working on this? I'm curious about it...

Well, are you?
There's such a thing as deciding on a course of action.

ScummVM is meant to play old junk

It's funny that you say this

I think that's why he said it.
However, the rest of his point (that you punted to a mythical ScummVM dev) is good.

As I said above, it makes more sense to skip the middleman (ScummVM) and go straight to SDL.

[Snarky]

Well, ScummVM's portability is not solely due to SDL. If you look at the list of platforms, you see that a lot of them (crucially, almost all the portable devices) run on other backends.

Don't get me wrong, I'm not insisting that the ScummVM framework is the right way to go, particularly not in the short term. If we can get the engine as it is to run on MacOS and Linux, that would be great for now. I just think we should keep in mind that there's more to multiplatform support than those desktop OSes, and that ports to a lot of different systems is going to be a lot of work unless we can piggyback on some existing code. (In fact, a big hit against ScummVM in my book is that it doesn't offer a web runtime - whether Flash, Silverlight or HTML5/JS. I think that should be a higher priority than getting AGS games to run on for example the Dreamcast.)

[JenniBee]

If a ScummVM engine were used as the main codebase for AGS, you wouldn't have to worry about bloat.  ScummVM has the option at compile time to turn compiling of engines off.  It would be very easy to have an executable only for AGS games.  You'd only have to run ./configure --disable-all-engines --enable-ags which would give you a small executable only capable of running AGS games.

This executable could be packaged with the AGS editor and an all-inclusive binary could be distributed through ScummVM.  That way you'd get all the benefits of ScummVM (multiple platform support, backends are independent of the engine code meaning the AGS engine developers don't have to worry about maintaining the individual platform ports, scalers, etc.), and you wouldn't have to worry about extraneous engines that aren't needed.

[Edmundito]

Snarky's got the priorities right.

And it's actually easier said than done to port the engine to another toolset. It's not a walk in the park like the editor, and it needs a bit of significant cleanup before we can really all work on it. It was very much written for one guy to handle the code.

Looks like we also need to split up into different threads. There's a few conversations going on (Building the source, general discussion on what where the source should go in the future, actual more technical source changes coordination)

[Kweepa]

Ooops, I didn't realise SDL doesn't yet support iPhone or Android.
(There's a pre-release of SDL 1.3 that does.)
My mistake.

[Alan v.Drake]

[...]
I consider very humilliating your way of thinking to ScummVM, undervaluing classic videogames that are still considered as the best games of the adventure genre. They aren't "old junk" at all, but software to be preservated and able to use it in modern platforms.
[...]

Ahah, oh c'mon, I was using metaphors. I have played and enjoyed all the good ol' classics, obviously.
Otherwise I wouldn't be posting in this forum.

You made me post off-topic, happy now ?


- Alan

[Pumaman]

The source control provider associated with this solution could not be found. The projects will be treated as not under source control. Do you want to permanently remove the source control bindings from the projects?

Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

Thanks, I'll fix these in SVN.

1. Go to Project -> Properties...
2. Select All Configurations in the top left drop down
3. Under the tree Configuration Properties -> C/C++ -> General -> Additional Include Directories add ..\Common and ..\Common\libinclude

Nice one, I didn't know about that. I'll do that too.

In my opinion, the first step to make this useful is to break the 28,015 line AC.cpp monstrosity into sensible chunks, by feature. At first blush, I'd say something like this list:

That sounds sensible, but as you say, it's a big job and one that somebody would have to volunteer for...

A couple of headers are #include-d in all-lowercase, but they're in the filesystem in ALL-UPPERCASE or Mixed-Case. On Linux and most other OSes, filenames are case sensitive... Someone with the right permissions should

I'll look into this.

There's a copy of the Allegro headers in the source (Common/libinclude/allegro) -- some of those files should be autogenerated by the Allegro build process instead of being included (e.g. alplatf.h says #define ALLEGRO_MSVC). I can see a couple of possible fixes there:

Good point. It's done this way so that people using MSVC can easily build AGS without having to install Allegro separately. For Linux/other platforms, maybe the advice should be to delete the Allegro folder from Common/libinclude, which should allow it to fall-back on the system allegro installation.

Some files contain very Windows specific code (acwavi.cpp) - while it probably wouldn't be overly hard to replace acwavi.cpp with something using ffmpeg to do the same in a cross-platform way, I know there was a previous Linux port, so some code must already exist - before I start redoing it from scratch, is that code available somewhere?

As far as I remember, video playback was never implemented in the Linux port. Indeed, the acpllnx.cpp just stubs out the PlayVideo function.

A last request: Any chance for a release of the 2.x source code so we can get older games to run better on Linux?

I may well provide the source to legacy versions at a later date.

Is there any reason why there are the 2 virtually identical copies, other than not having enough time to fix an issue that hasn't caused major problems before (like not wanting to diverge too far from upstream apeg/almp3)? If so, given almp3 is no longer developed, can we fix it now?

Precisely, it hasn't caused a problem so far. If someone would like to take the time to investigate it and get both MP3 and Theora playing working with the same MPG123 codebase, that would be great.

Has anyone else looked into getting this to work on 64bit platforms yet?

The most serious show-stopper with a 64-bit version is that the script compiler and interpreter make some pretty wide-ranging assumptions about pointers being 32-bit. Fixing this would require significant refactoring of the script system, and considering that I can't see any benefits in AGS being a 64-bit process (I can't see it ever needing to use more than 3 GB RAM), I don't think it's worth it.

Ok. I'll PM you the link of the 272 & 312 project package, so you can review, and I'm not sure you want those released.

Thanks. I'd rather not release those versions of the 2.72 / 3.1.2 source code right now, I'd want to release them in a consistent state with 3.2.1.

- a working code::blocks project for AGS 3.2.1 with updated notes in the project

Great! Please do publically release this when you have it working!

[subspark]

Welcome to the forums, JenniBee and timofonic. Glad to see new blood here in the AGS circle.
I encourage you to skim through the various areas of our forum so that you can form a cognitive map of the general orientation/history/tastes/humor of our community.

This way, you'll find more in common with the friends you'll make here.

Again, welcome. 

[sigbuserror]

I just wanted to stop in again and thank everyone, i am now able to build my own ags bin using linux  Keep up the good work here and I will report back if I find anything significant I can contribute.

[JawCross]

Hi I'm interested in to get AGS compiled and working under (64-bit) Ubuntu.

I got Bero's ags-20110501-linux.tar.xz compiled (with add_definitions(-m32) ) but not linked yet. Problem is with libcda and libalfont, thanks Bero for links, I got them both compiled but not installed (they do not use 'make install' and I do not know what to do.

Bero, are you familiar with git and gitorious? Your patches are good, but it would be difficult to handle and use them when they scatter around forum. I haven't yet see any plans for merging them to the svn, so maybe they should be collected one place just now.

*
File libcda/libcda-0.5/COPYING contains zlib-license, but also some fuzzy license which covers files: djgpp.c, bcd.doc.

[timofonic]

Welcome to the forums, JenniBee and timofonic. Glad to see new blood here in the AGS circle.
I encourage you to skim through the various areas of our forum so that you can form a cognitive map of the general orientation/history/tastes/humor of our community.

This way, you'll find more in common with the friends you'll make here.

Again, welcome. 

Thanks for your greetings. Anyway I'm a lurker on different forums and participate just occasionally. I got bored of being a forum habitant over the years, sorry

Chris Jones: Did you develop AGS by using some source code revision control system? If you used one at least like CVS, importing to to the public SVN could be amazing for the community and even better than publishing legacy versions

[Electroshokker]

Some files contain very Windows specific code (acwavi.cpp) - while it probably wouldn't be overly hard to replace acwavi.cpp with something using ffmpeg to do the same in a cross-platform way, I know there was a previous Linux port, so some code must already exist - before I start redoing it from scratch, is that code available somewhere?

As far as I remember, video playback was never implemented in the Linux port. Indeed, the acpllnx.cpp just stubs out the PlayVideo function.

Actually, I implemented it using the gstreamer library (which is license-friendly) in my AGS 2.72 & 3.12 builds.
The linux video code will be in my 3.2.1 project build.

Ok. I'll PM you the link of the 272 & 312 project package, so you can review, and I'm not sure you want those released.

Thanks. I'd rather not release those versions of the 2.72 / 3.1.2 source code right now, I'd want to release them in a consistent state with 3.2.1.

- a working code::blocks project for AGS 3.2.1 with updated notes in the project

Great! Please do publically release this when you have it working!

Will do. Haven't had time yet this weekend to set it up, so probably later this week.

[Monsieur OUXX]

Ooops, I didn't realise SDL doesn't yet support iPhone or Android.

A few months earlier I had the exact same discussions with other guys (as part of a project called "Dune Revival") and it turns out the most common misconception about ScummVM is that it's an unnecessary wrapper for SDL.

It's quite the opposite. It adds more portability, and it's rather fast.

Just mentionning it, to save some time.

[timofonic]

Ooops, I didn't realise SDL doesn't yet support iPhone or Android.

A few months earlier I had the exact same discussions with other guys (as part of a project called "Dune Revival") and it turns out the most common misconception about ScummVM is that it's an unnecessary wrapper for SDL.

It's quite the opposite. It adds more portability, and it's rather fast.

Just mentionning it, to save some time.

In fact the engine is built on top of OSystem.

Anyway, SDL seems tisn't mandatory these days in a ScummVM build. There's an OpenGL backend too.

ScummVM runs even on Nintendo DS, Nintendo 64, Dreamcast, PlayStation 2, Game Cube, Wii, PSP, GP2X, Wiz, Dingux, Caanoo, Pandora, iPhone, Motorola Phones, Windows Mobile, Symbian, Android, Maemo WebOS platforms, Solaris, IRIX, Haiku, Amiga OS, Atari, OS/2... A big part of those platforms do not use SDL at all and  use custom backends without standard APIs like OpenGL too.

So what's the point? They developed a great portable framework over the years and are still perfectioning it over the time. It's an evolutionary software development in the style of the Linux kernel (20th Anniversary!)  in smaller scale, but they managed to do a good work even without paid developers other than Google Summer of Code ones

I just wanted to clarify it a bit more

[bero]

There's a copy of the Allegro headers in the source (Common/libinclude/allegro) -- some of those files should be autogenerated by the Allegro build process instead of being included (e.g. alplatf.h says #define ALLEGRO_MSVC). I can see a couple of possible fixes there:

Good point. It's done this way so that people using MSVC can easily build AGS without having to install Allegro separately.

I've made the cmake build just create alplatf.h based on the system detected - not sure if there's something similar you can do in MSVC.

For Linux/other platforms, maybe the advice should be to delete the Allegro folder from Common/libinclude, which should allow it to fall-back on the system allegro installation.

That's what I ended up doing in my latest build here, not so much to get around this problem (solved differently in the cmake files) but to reduce the code size.

As far as I remember, video playback was never implemented in the Linux port. Indeed, the acpllnx.cpp just stubs out the PlayVideo function.

I have a very primitive but somewhat working version by now (it simply calls mplayer).

I may well provide the source to legacy versions at a later date.

Please do, it would be great to be able to play 2.x games on Linux without having to install all sorts of compat libraries.

Is there any reason why there are the 2 virtually identical copies, other than not having enough time to fix an issue that hasn't caused major problems before (like not wanting to diverge too far from upstream apeg/almp3)? If so, given almp3 is no longer developed, can we fix it now?

Precisely, it hasn't caused a problem so far. If someone would like to take the time to investigate it and get both MP3 and Theora playing working with the same MPG123 codebase, that would be great.

I'll take a look when I have some time. Could take a while though, right now the day job is taking up pretty much all of my time.

The most serious show-stopper with a 64-bit version is that the script compiler and interpreter make some pretty wide-ranging assumptions about pointers being 32-bit. Fixing this would require significant refactoring of the script system, and considering that I can't see any benefits in AGS being a 64-bit process (I can't see it ever needing to use more than 3 GB RAM), I don't think it's worth it.

It's worth it on Linux because most 64-bit Linux systems are pure 64-bit systems - so if you want to run a 32-bit AGS, you have to first install 32-bit versions of all libraries AGS uses directly or indirectly.
I expect Apple will remove 32-bit compatibility from default installations of OSX at some point as well.

[bero]

Hi I'm interested in to get AGS compiled and working under (64-bit) Ubuntu.

I got Bero's ags-20110501-linux.tar.xz compiled (with add_definitions(-m32) ) but not linked yet. Problem is with libcda and libalfont, thanks Bero for links, I got them both compiled but not installed (they do not use 'make install' and I do not know what to do.

For libalfont, run (inside the alfont directory)

[code]
gcc -fPIC -DPIC -O2 -m32 -Iinclude `freetype-config --cflags` -o src/alfont.o -c src/alfont.c
gcc -O2 -m32 -shared -Wl,-soname,libalfont.so.2 -o libalfont.so.2.0.9 src/alfont.o `freetype-config --libs` `allegro-config --libs |sed 's/-lalleg_unsharable//'`
install -m 755 libalfont.so.2.0.9 /usr/lib/
install -m 644 include/alfont*.h /usr/include/
ln -s libalfont.so.2.0.9 /usr/lib/libalfont.so.2
ln -s libalfont.so.2.0.9 /usr/lib/libalfont.so.2
[/code]

For libcda, run (inside the libcda directory)

[code]
gcc -O2 -m32 -fPIC -DPIC -o linux.o -c linux.c
gcc -O2 -m32 -g -shared -Wl,-soname=libcda.so.0 -o libcda.so.0 linux.o
install -m 755 libcda.so.0 /usr/lib/
mkdir /usr/include/libcda
install -m 644 libcda.h /usr/include/libcda/
[/code]

Also, if you used make instead of following my build instructions, make sure the libraries are built with -m32 as well, you can't link a 32bit executable (ags) to 64bit libraries, and building ags as native 64bit application will require LOTS of work. (I'm not using make for alfont because I don't want its internal copy of an outdated freetype, and I'm not using make for libcda to make sure I'm not dragging in files with questionable licenses).
For porting to native 64bit, I have some code to begin with, but it's nowhere near working yet.

Bero, are you familiar with git and gitorious?

Yes, I'm a Qt guy...

Your patches are good, but it would be difficult to handle and use them when they scatter around forum. I haven't yet see any plans for merging them to the svn, so maybe they should be collected one place just now.

I agree, the only reason why I haven't done it so far is that I don't want to piss off the AGS devs by doing something that might be mistaken for an attempt to hijack the project.
But I guess as long as it's clear we don't intend to do that, and it's just a staging ground for portability patches, we can do it. I'll create a project and post the URL.

File libcda/libcda-0.5/COPYING contains zlib-license, but also some fuzzy license which covers files: djgpp.c, bcd.doc.

No need to worry about the djgpp.c license (it's for the DOS port) or the bcd.doc license (documentation, no need to build/package/install it, or even to read it while everything is working).
The only file in libcda that is needed for Linux people is linux.c

[Edmundito]

Ok! Progress with the mac port. I've been writing down the things I've been patching and some of the known isssues. Will post that stuff later.

Got as close as to the linking process (OMG) except for a couple of issues:

[code]
  "_main", referenced from:
      start in crt1.10.6.o
     (maybe you meant: __mangled_main_address, _display_main(int, int, int, char*, int, int, int, int, int, bool), _mangled_main(int, char**), calculate_destination_size_maintain_asp ect_ratio(int, int, int*, int*), _maincoltable ,
[/code]

Can't find main to link. I sort of got familiar with what allegro is doing under the hood. It turns out there's some funky changes in the latest version of Mac OS's sdk, which was fixed in the latest version of allegro, but the whole implementation of the mangling in allegro 5 is very different from 4, so I've yet to figure out how to patch it correctly. I'm assuming that AGS is using a MAGIC_MAIN, correct?

[code]
load_main_block(roomstruct*, char*, __sFILE*, room_file_header), do_main_cycle(int, int))
  "_FT_New_Face", referenced from:
      _alfont_load_font in libalfont.a(alfont.o)
[/code]

Known mac issue with freetype. Have not found an answer to this one yet. I'm using Electroshokker's alfont source.

[kingstone]

I agree, the only reason why I haven't done it so far is that I don't want to piss off the AGS devs by doing something that might be mistaken for an attempt to hijack the project.
But I guess as long as it's clear we don't intend to do that, and it's just a staging ground for portability patches, we can do it. I'll create a project and post the URL.

Looking forward to it!

[bero]

I agree, the only reason why I haven't done it so far is that I don't want to piss off the AGS devs by doing something that might be mistaken for an attempt to hijack the project.
But I guess as long as it's clear we don't intend to do that, and it's just a staging ground for portability patches, we can do it. I'll create a project and post the URL.

Looking forward to it!

Done, my port is now imported into http://gitorious.org/ags.

Feel free to do anything you like with it, and add to the wiki.

[RedDwarf]

Done, my port is now imported into http://gitorious.org/ags.

Feel free to do anything you like with it, and add to the wiki.

You have a merge request there. Not really used to git, hope everything is correct.

[bero]

You have a merge request there. Not really used to git, hope everything is correct.

Thanks, looks mostly good to me - I've added a comment on it w/ a couple of remarks and questions.

[Edmundito]

Do you believe in magic?

[subspark]

No. I believe in technology however and you just improved it a great deal!
Well done Edmundito. Well done indeed. 

Sparky. [claps hands]

[Calin Leafshade]

Done, my port is now imported into http://gitorious.org/ags.

Feel free to do anything you like with it, and add to the wiki.

While I think that is awesome doesn't it contravene the license?

Specifically the "You may not distribute this code" part?

Do you believe in magic?

That is also awesome!

...

Does this mean i need to make a mac and linux version of Nimbus? D:

[bero]

While I think that is awesome doesn't it contravene the license?

Specifically the "You may not distribute this code" part?

Quoting the announcement of the source code release (first post on this thread in the forum):

I know there's been a lot of interest in this, so if you're a C++ programmer then the code is now available for your perusal. It's released under the Artistic License 2.0, as with the editor code.

You can read the Artistic License 2.0 here - it clearly says anyone is allowed to distribute modified code under certain conditions we comply with. If there's any "You may not distribute this code" statements left anywhere, I consider them to be obsoleted by that announcement. Correct me if I'm wrong.

Does this mean i need to make a mac and linux version of Nimbus? D:

Of course.

[redspark]

Do you believe in magic?

That's awesome!  I can't wait to start trying it out.

[monkey_05_06]

Now if only I didn't hate Mac OS slightly more than I hate Windows..:

[Dualnames]

It seems that the man that brought awesome to our AGS games with Tweenmodule just did it again. Way to go, Edmundito!!!!!!! 

[RedDwarf]

Looking at the acwin.vcproj I see all the builds, with and without MP3 support, use "DISABLE_MPEG_AUDIO"; which disables MP3 support in apeg without touching almp3. Not sure what are the consequences, since I'm not sure what apeg is used for. But is this expected? No game should suppose ags was build with a copy of apeg with mpg123 support? Since bero is working in being able to have both copies of mpg123 at the same time...

[bero]

Looking at the acwin.vcproj I see all the builds, with and without MP3 support, use "DISABLE_MPEG_AUDIO"; which disables MP3 support in apeg without touching almp3. Not sure what are the consequences, since I'm not sure what apeg is used for. But is this expected? No game should suppose ags was build with a copy of apeg with mpg123 support? Since bero is working in being able to have both copies of mpg123 at the same time...

Educated guess from reading through the code: almp3 is used to play plain sound files (test for almp3: rip out the cat hair in kq3redux, the cat's response is mp3).

apeg seems to play videos that may or may not have an mp3 soundtrack. So yes, both are needed... (And the fix to make both use the same mpg123 is on its way... Good idea anyway, given how many security bugs old mpg123 had)

[helios123]

Like many other people, I have also been busy experimenting with the source for the last couple of days. Here are a few things that I found out:

• I am using Code::Blocks, as the development environment, with the Visual C++ 2008 compiler. Code::Blocks supports importing Visual Studio solution files, so setting up  the project is comparatively easy. We only have to add the lib files in the linker's configuration.
  
• CJ's original post mentions that DirectX SDK is required. But I found that this is not required if you have Windows SDK installed, as it includes the DirectX headers and libs.
  

• You will need Visual C++ Express 2008 (this is a free download from MS). Do NOT use the 2010 version, this will probably not work and let's not complicate things at this stage by trying to use it.

  In spite of this, I tried (out of curiosity, and the fact that support for Visual C++ 2008 Express is likely to be dropped sometime in the near future) to compile the engine using Visual C++ 2010 Compiler (it's bundled in the Windows SDK) using Code::Blocks as the IDE (Note that Code::Blocks does not detect Visual C++ 2010 compiler automatically. We have to manually configure it through Settings -> Compiler and Debugger).
  
  The code compiled (only a single change of typecasting in a call to the abs function had to be made), but the linker complained that it could not resolve a reference to _hypot function in alleg_s_crt.lib. After a little find in files and examining the contents of the allegro 5 dll using objdump (I'm afraid I don't know the MSVC equivalent), I found that the function _hypot is present in msvcrt.dll (which is not being linked, but is probably referred by alleg_s_crt.lib). But it is also in libcmt.lib (which is being linked).
  
  The puzzling thing here (at least to me), is that the same thing works in Visual C++ 2008, while it does not work in Visual C++ 2010.
  Is this the reason why use of Visual C++ 2010 was discouraged, or am I doing something wrong, or is this due to something else?
  

[Electroshokker]

Considering the headway you guys have been making (and my own lack of time and struggle with the almp3 & apeg integrations in 3.2.1), I figure I'd just release the linux video code which you can use as a starting point for proper unix video integration.

Here it is!

the GStreamer api & documentation

GStreamer is a plugin-based framework licensed under the LGPL. (for license mumbo jumbo, read here)

Also, I'd like to note that Allegro 4.4 is fully backwards compatible with 4.2 AND has OpenGL support.

Here's the challenge for you guys:

- working AGS 3.2.1 build on Linux, Mac
- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)
- redesign audio support to use gstreamer, so audio will work properly on all platforms
- create ags plugin support on linux & mac

Have fun with it! If you've got questions, feel free to ask.

[RedDwarf]

- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)

Done... but I don't know how to test it. Any game that is known to require it and work with 3.2? KQ3 has video intro, but it worked before... through apeg/Theora, I suppose.

- redesign audio support to use gstreamer, so audio will work properly on all platforms

Would be nice. But isn't audio working already?

- create ags plugin support on linux & mac

I don't know how the ags plugin system works. But even if added for linux & mac, I suppose already existing plugins wouldn't work since they are compiled for Windows, aren't? They could depend on Windows only libraries... and IIRC the C++ ABI is just different there.

[bero]

- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)

Done...

Great, then I won't touch it until you're ready. No need to duplicate work...

but I don't know how to test it. Any game that is known to require it and work with 3.2? KQ3 has video intro, but it worked before... through apeg/Theora, I suppose.

So far I haven't noticed it missing anywhere either - and I couldn't test my quick-and-dirty one-liner approach (system("mplayer whatever");") either.

- redesign audio support to use gstreamer, so audio will work properly on all platforms

Would be nice. But isn't audio working already?

It is -- it's using almp3/alogg/apeg/libcda, which is a bit of a mess (too many different bits), but it works everywhere. It's a bit less messy now that I've adapted it to use current mpg123 rather than the old internalized copy.
(And I'd argue anything using gstreamer would be a bit of a mess as well, while it works well, I think gstreamer's code is rather awful. But then I'm somewhat biased, I tend to think anything that uses glib is broken by design)

- create ags plugin support on linux & mac

I don't know how the ags plugin system works. But even if added for linux & mac, I suppose already existing plugins wouldn't work since they are compiled for Windows, aren't? They could depend on Windows only libraries... and IIRC the C++ ABI is just different there.

There could be a way to do it by stealing wine's PE loader and most of wine's libraries, but then there wouldn't be much of a point in having AGS natively in the first place because people could just use all of wine. (And of course any attempt to do that on non-x86 Linux (the rest of AGS should work on ARM...) would be doomed to fail.)
It's probably best to just provide an identical API so people can just recompile their plugins to any platform (preferrably releasing the source so people on *BSD, Solaris and whatever can build their own).

[Wyz]

Yes, that would definitely be the best option. I've guaranteed cross-platform support for all plugins I've madeso far in that I will either port it myself or release the source code. If you need plugins to test with: let me know.

[bero]

Yes, that would definitely be the best option. I've guaranteed cross-platform support for all plugins I've madeso far in that I will either port it myself or release the source code. If you need plugins to test with: let me know.

I do - please make a plugin source plus a test game available somewhere, and point me to it.
Thanks!

[Wyz]

I've made a test plugin because I want to be sure the interface is a broad as possible. It is tested (except for saving and loading) but I didn't feel like writing a test game for it. It simply wraps vector<string> and everything gets called from the Array namespace (and has auto-completer hints).

The source:
https://code.google.com/p/ags-plugin-stringarray/source/checkout

[GrogGames]

i tried to compile ags port from http://gitorious.org/ags  in ubuntu 11.04 i386 live cd.
I installed all the libraries with synaptic, except allegro libalfont and libcda. For libcda and libalfont i used this
for libalfont
[code]
gcc -fPIC -DPIC -O2 -m32 -Iinclude `freetype-config --cflags` -o src/alfont.o -c src/alfont.c
gcc -O2 -m32 -shared -Wl,-soname,libalfont.so.2 -o libalfont.so.2.0.9 src/alfont.o `freetype-config --libs` `allegro-config --libs |sed 's/-lalleg_unsharable//'`
install -m 755 libalfont.so.2.0.9 /usr/lib/
install -m 644 include/alfont*.h /usr/include/
ln -s libalfont.so.2.0.9 /usr/lib/libalfont.so.2
ln -s libalfont.so.2.0.9 /usr/lib/libalfont.so.2
ln -s libalfont.so.2.0.9 /usr/lib/libalfont.so
[/code]

For libcda
[code]
gcc -O2 -m32 -fPIC -DPIC -o linux.o -c linux.c
gcc -O2 -m32 -g -shared -Wl,-soname=libcda.so.0 -o libcda.so.0 linux.o
install -m 755 libcda.so.0 /usr/lib/
mkdir /usr/include/libcda
install -m 644 libcda.h /usr/include/libcda/
ln -s libcda.so.0 /usr/lib/libcda.so
[/code]
for allegro, i downloaded the 4.4 source and compiled.
that works fine, but when i try to compile ags, i received this message
[code]
Linking CXX executable ags
/usr/lib/libalfont.so: undefined reference to `_msize'
collect2: ld returned 1 exit status
make[2]: *** [Engine/ags] Error 1
make[1]: *** [Engine/CMakeFiles/ags.dir/all] Error 2
make: *** [all] Error 2
[/code]


thanks for help, sorry if I express wrong, i speak spanish

[JawCross]

I have also problems with Ubuntu. I first tried under 64 bit, but now I'm trying with 32 bit.

I copied instructions from forum to the wiki:
https://gitorious.org/ags/pages/HowToBuild#Building+under+Ubuntu
I fixed one non-printing character and ln -s libalfont.so.2.0.9. (Are these correct now?)


My problem is cmake is not founding alfont and libcda. Is there still some details missing in instructions?

[GrogGames]

I have also problems with Ubuntu. I first tried under 64 bit, but now I'm trying with 32 bit.

I copied instructions from forum to the wiki:
https://gitorious.org/ags/pages/HowToBuild#Building+under+Ubuntu
I fixed one non-printing character and ln -s libalfont.so.2.0.9. (Are these correct now?)


My problem is cmake is not founding alfont and libcda. Is there still some details missing in instructions?

YES!  =)
i found that details!
check the wiki now, i added that details.

A question, when you run "cmake .". Do you not receive a message "package allegro not found"?
With allegro 4.2 i receive that message, then i has to compile allegro 4.4, and the message disappeared.


with that instructions now compile! thanks  =)

[JawCross]

I tested under Ubuntu 10.10 (Maverick).

cmake gives "package allegro not found"? But it doesn't brake and make will also pass.

[JawCross]

I tried compile Editor under Ubuntu (10.10) using mono.
There were some trivial issues* I fixed and pushed my git clone.

Compiling stops on error "Compiler crashed with code: 1"
I do not know how to proceed with it.

*Fixed:
- error CS1587: XML (error about comments)
- "value never used"-warnings are treated as error
- used small d, but filename has capital D.

-
Steps to reproduce
sudo apt-get install mono-xbuild mono-2.0-devel libmono-winforms*

git clone git://gitorious.org/~aaporantalainen/ags/aaporantalainens-ags.git ags
cd ags/Editor
xbuild AGS.Editor.NoNative.sln

[Electroshokker]

[RedDwarf]

Heheheh... actually, it CAN be fixed without getting a patch into Allegro... at least for the linux build.

I'll dig through my sources and give you guys a set of pointers and examples. For now, take a look at this linker command: [code]-Wl,-wrap,pack_fopen[/code]
If you look it up you'll find the technique I used...

That doesn't seems to work. The idea seems to be that allegro functions also use ags's pack_fopen (otherwise would be no need to name that function pack_fopen). Since allegro wasn't compiled with the wrap functions this trick doesn't work.

Anyway I created two branches:
- allegro_wrap: Uses Electroshokker trick. Probably depends on GNU ld and as explained I don't think it really works... but I could not find problems when using it.
- allegro_wrap2: When available, uses a GLIBC extension for dlsym which makes the internal pack_fopen functions unneeded. In this case allegro functions also use it.


Totally unrelated, with mpg123 1.13.3 I don't get any MP3 sounds (cat in KQ3). It worked before with the internal copy. It's just me?

[Calin Leafshade]

I tried compile Editor under Ubuntu (10.10) using mono.

Not a great deal of point. The AGS Editor is not pure .net and uses alot of P/Invoke calls for the debugger.

To make the editor work coherently you would need to completely rewrite the debugger interface on both the editor and the engine

[RedDwarf]

Totally unrelated, with mpg123 1.13.3 I don't get any MP3 sounds (cat in KQ3). It worked before with the internal copy. It's just me?

The code, at the very least, lacks a call to mpg123_init().
bero, the code was untested or you forgot to add a file in the commit?

[Electroshokker]

Heheheh... actually, it CAN be fixed without getting a patch into Allegro... at least for the linux build.

I'll dig through my sources and give you guys a set of pointers and examples. For now, take a look at this linker command: [code]-Wl,-wrap,pack_fopen[/code]
If you look it up you'll find the technique I used...

That doesn't seems to work. The idea seems to be that allegro functions also use ags's pack_fopen (otherwise would be no need to name that function pack_fopen). Since allegro wasn't compiled with the wrap functions this trick doesn't work.

Anyway I created two branches:
- allegro_wrap: Uses Electroshokker trick. Probably depends on GNU ld and as explained I don't think it really works... but I could not find problems when using it.
- allegro_wrap2: When available, uses a GLIBC extension for dlsym which makes the internal pack_fopen functions unneeded. In this case allegro functions also use it.


Totally unrelated, with mpg123 1.13.3 I don't get any MP3 sounds (cat in KQ3). It worked before with the internal copy. It's just me?

Ahum, it's not simply a matter of adding this command, you have to change the ags code using wrapper functions which point to the real function. If you do that, you don't have to change the AGS library.

see (just dug up this link, there are other locations which explain it better) http://stackoverflow.com/questions/3662856/how-to-reimplement-or-wrap-a-syscall-function-in-linux

If you can't work this out, I'll post my entire ags code section which uses this when I'm on my home pc. (at work now)

[RedDwarf]

Ahum, it's not simply a matter of adding this command, you have to change the ags code using wrapper functions which point to the real function. If you do that, you don't have to change the AGS library.

see (just dug up this link, there are other locations which explain it better) http://stackoverflow.com/questions/3662856/how-to-reimplement-or-wrap-a-syscall-function-in-linux

If you can't work this out, I'll post my entire ags code section which uses this when I'm on my home pc. (at work now)

I know it isn't just adding the linker command. You have the full commit at https://gitorious.org/~reddwarf/ags/reddwarfs-ags/commit/f4099e49bd0b5896091eab61086f6dad9539e16c

But what it does is modify references to pack_fopen into __wrap_pack_fopen, and references to __real_pack_fopen into pack_fopen. It does not change the definitions, so you end with an ags executable with a symbol table that includes a __wrap_pack_fopen definition, no a pack_fopen definition. So, when loading the allegro library (dynamically linked), the loader will resolve references to pack_fopen to the internal library definition... since there is no other pack_fopen definition.
The references to pack_fopen in the allegro_library are never changed to __wrap_pack_fopen since the allegro library wasn't linked with the -wrap option.

To make it clear. If you run this code
[code]#include <stdio.h>
#include <allegro.h>

PACKFILE *__real_pack_fopen(const char *, const char *);

PACKFILE *__wrap_pack_fopen(const char *filnam, const char *modd) {
  printf("Wrapper_function\n");
  __real_pack_fopen(filnam, modd);
}

int main() {
    load_wav("sample.wav");
    printf("Separator\n");
    pack_fopen("sample.wav", "r");
    return 0;
}[/code]

You get

Separator
Wrapper_function

even when load_wav internally calls pack_fopen.

[JawCross]

I tested AGS on Linux-ARM. I got it compiled and it can be started, but it is not really working yet.

I collected every build warnings to: https://gitorious.org/ags/pages/StateOfArmSupport

Currently I know only one game, which is working with AGS-3.21: Kings Quest III Redux. Can you suggest some more test cases?

This is what I get in terminal:
./ags Kq3Redux.exe
[code]
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones

ACI version 3.21.1115
Speech sample file found and initialized.
Audio vox found and initialized.
Checking sound inits.
install_sound(-1,-1)

Unable to initialize your audio hardware.
[Problem: ALSA: snd_pcm_hw_params_set_format(pcm_handle, hwparams, format) : Invalid argument]
[/code]

On the screen I get Game's logo, but after half a second it will be messed (see: http://imageshack.us/f/801/screenshot2011051815332.png ). Then nothing happens until I press key or mouse and then it dies silently.

So there are issues with (at least) audio and graphics, but are some of them fatal (why it shutdowns)?

[JJS]

I am working on a PSP port right now, which is basically done except for the onscreen keyboard and customizable controls.

The PSP has a MIPS processor and you may have the same problem on ARM. The script engine regularly casts values to int pointers which are not 4 byte aligned. That is not allowed on the PSPs processor. So I replaced these instances with memcpy functions.

Also the bitmap font rendering uses unaligned pointers.

Here is a patch (against the SVN) that works for me. It includes some PSP specific changes too. But every single change is documented, so you should be able to gain something from it if the problem is in fact the same.

http://jjs.at/temp/pointer_alignment.patch

Edit: It might also be important that I can build all source with -O2 optimization except for ac.cpp which has to be with -O2 -fno-strict-overflow -fno-strict-aliasing . Otherwise there are strange scripting errors.

[JawCross]

JJS, thanks for PSP-patch. It doesn't change user experience, but now it does not silently die, but it is Segmentation Fault always.

I'm not sure about optimization flags, I'm currently trying with Debug release.

I got first backtrace, which seems almost useless to me:
[code]
#0  0x0018f258 in _linear_hline16 ()
#1  0x0020564c in _xwin_hline ()
#2  0x0015a508 in _normal_rectfill ()
#3  0x0020515c in _xwin_rectfill ()
#4  0x00053c88 in rectfill (bmp=0x645a40, x1=0, y_1=0, x2=319, y2=199, color=0) at /usr/include/allegro/inline/draw.inl:88
#5  0x00054280 in AllegroGFXFilter::ClearRect (this=0x644868, x1=0, y1=0, x2=319, y2=199, RGB=0)
    at ags_maemo/Engine/acgfx.cpp:439
#6  0x000de038 in ALSoftwareGraphicsDriver::ClearRectangle (this=0x6448f8, x1=0, y1=0, x2=319, y2=199, colorToUse=0x0)
    at ags_maemo/Engine/ali3dsw.cpp:340
#7  0x0005f040 in display_switch_in () at ags_maemo/Engine/ac.cpp:15574
[/code]

(None of those three Engine/ files were touched by psp-patch)

Allegro is not widely used on Maemo, but at least very simple test is working: http://wiki.allegro.cc/index.php?title=ExampleExHello

[RedDwarf]

Totally unrelated, with mpg123 1.13.3 I don't get any MP3 sounds (cat in KQ3). It worked before with the internal copy. It's just me?

The code, at the very least, lacks a call to mpg123_init().
bero, the code was untested or you forgot to add a file in the commit?

Nevermind. I'm rewriting the MP3 code without using ALMP3.

I have the MYSTATICMP3 part. Once I have the MYMP3 part and I clean it I will request a merge.

[RedDwarf]

The new mp3 playback code is commited and there is a merge request.

Now, how are we going to handle all this? This commit is not Linux specific. Pumaman, will you look into the git log to take patches for your SVN? I don't see a way to make it easier for you. I could attach a patch here, but that is not going to make it easier (in fact Gitorious has a really nice diff/patch viewer). Gitorious really makes collaboration easier.

[RedDwarf]

JJS, thanks for PSP-patch. It doesn't change user experience, but now it does not silently die, but it is Segmentation Fault always.

I'm not sure about optimization flags, I'm currently trying with Debug release.

I got first backtrace, which seems almost useless to me:
[code]
#0  0x0018f258 in _linear_hline16 ()
#1  0x0020564c in _xwin_hline ()
#2  0x0015a508 in _normal_rectfill ()
#3  0x0020515c in _xwin_rectfill ()
#4  0x00053c88 in rectfill (bmp=0x645a40, x1=0, y_1=0, x2=319, y2=199, color=0) at /usr/include/allegro/inline/draw.inl:88
#5  0x00054280 in AllegroGFXFilter::ClearRect (this=0x644868, x1=0, y1=0, x2=319, y2=199, RGB=0)
    at ags_maemo/Engine/acgfx.cpp:439
#6  0x000de038 in ALSoftwareGraphicsDriver::ClearRectangle (this=0x6448f8, x1=0, y1=0, x2=319, y2=199, colorToUse=0x0)
    at ags_maemo/Engine/ali3dsw.cpp:340
#7  0x0005f040 in display_switch_in () at ags_maemo/Engine/ac.cpp:15574
[/code]

(None of those three Engine/ files were touched by psp-patch)

In a Linux machine a very similar crash happens when you exit. Perhaps you have another problem that triggers a normal quit (which could give a useful message) and it segfault because of the quitting.
You should be able to comment the
[code]
  if (gfxDriver->UsesMemoryBackBuffer())  // make sure all borders are cleared
    gfxDriver->ClearRectangle(0, 0, final_scrn_wid - 1, final_scrn_hit - 1, NULL);
[/code]
part of display_switch_in. I'm not even sure it makes sense at all.

You could also look at the backtrace of all the threads (that one isn't the main one) and search for the quit call (which will contain the message explaining why it was called).

[JJS]

It would make sense that this is a crash on quitting because the message that gets drawn on screen (the one from the screenshot) says that speech.vox is not available. After dismissing this box with a keypress the game quits.

You asked for other test cases, what I did was compiling some games myself which are open source like ! and the Oceanspirit Dennis games. Also of course the demo game that comes with AGS. Other games for 3.2x are (in no particular order or reason for selection): Aeronuts, Beacon, Eternally Us, Hardspace, The Hamresanden Chronicles II: The Black Prism, Of the Essence, The Lurking Horror, Next to Evil, Fountain of Youth Demo/Arcade Fighter, Gemini Rue, etc. Really a lot of games, especially also newer MAGS ones.

[JawCross]

[code]
  if (gfxDriver->UsesMemoryBackBuffer())  // make sure all borders are cleared
    gfxDriver->ClearRectangle(0, 0, final_scrn_wid - 1, final_scrn_hit - 1, NULL);
[/code]

With this modification game (Kq3Redux) is not segfaultting on ARM, but it just ends. Debugger says: Program exited with code 0133.

You could also look at the backtrace of all the threads (that one isn't the main one) and search for the quit call (which will contain the message explaining why it was called).

[code]
gdb) thread apply all backtrace

Thread 9 (Thread 0x46cfb490 (LWP 1707)):
#0  0x403b0798 in poll () from /lib/libc.so.6
#1  0x424676b8 in ?? () from /usr/lib/libpulse.so.0
#2  0x424676b8 in ?? () from /usr/lib/libpulse.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0x454fb490 (LWP 1704)):
#0  0x403b0798 in poll () from /lib/libc.so.6
#1  0x424676b8 in ?? () from /usr/lib/libpulse.so.0
#2  0x424676b8 in ?? () from /usr/lib/libpulse.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0x4105a490 (LWP 1700)):
#0  0x0018f258 in _linear_hline16 ()
#1  0x0020564c in _xwin_hline ()
#2  0x0015a508 in _normal_rectfill ()
#3  0x0020515c in _xwin_rectfill ()
#4  0x00053c88 in rectfill (bmp=0x645d70, x1=0, y_1=0, x2=319, y2=199, color=0) at /usr/include/allegro/inline/draw.inl:88
#5  0x00054280 in AllegroGFXFilter::ClearRect (this=0x644888, x1=0, y1=0, x2=319, y2=199, RGB=0)
    at ags_maemo/Engine/acgfx.cpp:439
#6  0x000de038 in ALSoftwareGraphicsDriver::ClearRectangle (this=0x644918, x1=0, y1=0, x2=319, y2=199, colorToUse=0x0)
    at ags_maemo/Engine/ali3dsw.cpp:340
#7  0x0005f040 in display_switch_in () at ags_maemo/Engine/ac.cpp:15574
#8  0x0015435c in _switch_in ()
#9  0x001b7998 in _xwin_private_handle_input ()
#10 0x001b8028 in _xwin_handle_input ()
#11 0x001aea1c in _xwin_bg_handler ()
#12 0x001e1a2c in bg_man_pthreads_threadfunc ()
#13 0x40559934 in start_thread () from /lib/libpthread.so.0
#14 0x403b9be8 in clone () from /lib/libc.so.6
#15 0x403b9be8 in clone () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x40021c90 (LWP 1697)):
#0  0x4055d27c in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x403c5cc8 in pthread_mutex_lock () from /lib/libc.so.6
#2  0x001e1774 in _unix_lock_mutex ()
#3  0x00201c50 in x_set_leds ()
#4  0x001609d8 in set_leds ()
#5  0x00161434 in remove_keyboard ()
#6  0x0014045c in allegro_exit ()
#7  0x0007bab4 in quit (quitmsg=0x21a3c0 "|You have exited.")
    at ags_maemo/Engine/ac.cpp:9341
#8  0x000a0af8 in QuitGame (dialog=0) at ags_maemo/Engine/ac.cpp:17995
#9  0x000ecb04 in call_function (addr=658100, numparm=1, parms=0xbefeb128, offset=0)
    at ags_maemo/Common/csrun.cpp:1224
#10 0x000f0aa0 in cc_run_code (inst=0x628588, curpc=101913)
    at ags_maemo/Common/csrun.cpp:1798
#11 0x000f1704 in ccCallInstance (inst=0x656d6167, funcname=0x0, numargs=1)
    at ags_maemo/Common/csrun.cpp:2026
#12 0x000bcaf4 in run_script_function_if_exist (sci=0x628588, tsname=0x2e1a10 "game_start", numParam=0, iparam=0, iparam2=0, iparam3=0)
    at ags_maemo/Engine/ac.cpp:3273
#13 0x000bd8ec in run_text_script (sci=0x628588, tsname=0x21d578 "game_start")
    at ags_maemo/Engine/ac.cpp:3323
#14 0x000bda20 in start_game () at ags_maemo/Engine/ac.cpp:26661
#15 0x000be6ac in initialize_start_and_play_game (override_start_room=0, loadSaveGameOnStartup=0x0)
    at ags_maemo/Engine/ac.cpp:26818
#16 0x000c7d4c in initialize_engine (argc=2, argv=0xbefec2e4)
    at ags_maemo/Engine/ac.cpp:28045
#17 0x000c8ae8 in main (argc=2, argv=0xbefec2e4) at ags_maemo/Engine/ac.cpp:27243
[/code]

Maybe that ARM 'port' should wait till all big know issues are solved e.g. 64bit Linux works flawlessly. Maybe some old fancy dependencies should also be thrown away (like libcda).

[JawCross]

This is only coordination attempt I have seen so far. But is there more project site than svn.bigbluecup.com and https://gitorious.org/ags ? I think two is not yet fatal at all. And I hope official ('blessed') codebase will move to gitorious as well.

RedDwarf, what is your target and plans? I can see you have removed almp3 and added some gstreamer -stuff on your branches. Bero, you started cmake-clone for easy building (under Linux), and you have wrote about 64bit systems. Everybody else can also answer: "What is your goal? Short term all long term". I haven't see new commits on https://svn.bigbluecup.com:7743/svn/ags/trunk/ nor any sings that 'community effort will be merged to it'. I think they should be merged and I think there should be some plan (or hope) that they will be merged.

[RedDwarf]

#7  0x0007bab4 in quit (quitmsg=0x21a3c0 "|You have exited.")
    at ags_maemo/Engine/ac.cpp:9341
#8  0x000a0af8 in QuitGame (dialog=0) at ags_maemo/Engine/ac.cpp:17995

So something is triggering a normal exit.

RedDwarf, what is your target and plans? I can see you have removed almp3 and added some gstreamer -stuff on your branches. Bero, you started cmake-clone for easy building (under Linux), and you have wrote about 64bit systems. Everybody else can also answer: "What is your goal? Short term all long term". I haven't see new commits on https://svn.bigbluecup.com:7743/svn/ags/trunk/ nor any sings that 'community effort will be merged to it'. I think they should be merged and I think there should be some plan (or hope) that they will be merged.

My plan is make it work in Linux without crashes and with the same features than in Windows, nothing else. I never used ags at all for being closed source, so I don't know it to tell if it lacks any feature.
I may still look into the plugins thing (I would still want a test game), but nothing else. x86-64 support seems too complex.

[Dualnames]

This may be wrong, but i can't for the life of me figure this out. This is on the AGSEditor, on the NormalGUI.cs

[code]
 private Settings _settingsx;
              public NormalGUI() : base()        {
            _settingsx = new Settings();
            _width = Utilities.GetGameResolutionWidth(_settingsx.Resolution);
            _height = Utilities.GetGameResolutionHeight(_settingsx.Resolution);
         
            _x = 0;
            _y = 0;
         _bordercol = 2;
      }
[/code]

I'm obviously supposedly trying to set the gui's dimensions to the ones of the resolution when you add one. But somehow all my gui's end up 320x200.

[monkey_05_06]

Dual, this is the engine source thread, not the editor thread.

Anyway, I think that it might actually have something to do with low-res versus high-res/native coordinates, not actually trying to set the default size of the GUI to the game resolution. But I could be wrong, and don't have time to look right now.

[JJS]

Finally, here is an initial AGS runtime port to the PSP.

There are some restrictions, especially this port cannot run high-res games because the native resolution of the PSP is only 480x272 pixels. Also memory demanding games will run out of memory and crash. More about this is written in the readme.

What this port can do is run games requiring certain plugins like snowrain because the plugin exports are implemented as function stubs. This means you can e.g. run Gemini Rue with this (without the rain effects of course).

http://www.jjs.at/temp/AGS_for_psp_3.2.1.zip

Edit: Please use the updated version from this thread.


Are there plans to release the 3.1 and 2.7 source too? Edit: I guess that was already answered. I will stay tuned.

[subspark]

Holy Schnouzer dude. Well done! This is entirely new ground for AGS!
Bravo!

[Joseph DiPerla]

Nice! Now I need to get me a PSP.


OK, I am making a request for the geniuses out here... ANDROID PORT.

[Kyari]

Had a quick play around with Gemini Rue on a PSP 2000, seems to work pretty darn well, with the obvious exception of the rain effect everything seemed to run well.

[subspark]

Screen 7 - Fountain of Youth on PSP
http://www.bigbluecup.com/yabb/index.php?topic=42508.0

Paul.

[LimpingFish]

Hah, this is awesome!

Amazing work, JJS.

I managed to run the intro to my MAGS game Dead Hand, which runs in 320x240, and it looked really nice. Unfortunately, it crashed once it tried to load the first room (1280x960). I'm running it on a 1000, so that probably explains it.

Still, really nice work.

I suggest starting a separate thread for your project.

[Mati256]

This is awesome JJS!
Maybe some day we will see a Symbian and Android port.

[Shane 'ProgZmax' Stevens]

Very nice.  I'll echo the android port thing, since I'm actually going to be developing some games for that platform shortly and wouldn't mind being able to use ags here and there .

[abstauber]

I suppose that only makes sense, when the Allegro Android port is done But having AGS on touchscreen device would be great.

[subspark]

I think an iOS port of AGS deserves the second place in line but this is just me and my wishful thinking.
Oh and I don't have an android. But I sure would like to see AGS move out of the mother nest and go lay some eggs on some other platforms.

[Kyari]

Sorry to bump this after several weeks of inactivity, but I was just curious as to what happened with this thread?
Did it just fizzle out, or is there work being done by people behind the scenes or using somewhere else to discuss matters?

[Khris]

I believe several people are currently working on 3.2.2 using a CVS, yes.

[helios123]

I believe several people are currently working on 3.2.2 using a CVS, yes.

I think you mean SVN. Or is there a new separate CVS repository? Also I could find a 3.2.2 branch in SVN for the editor, but not for the engine. Is the engine code in some new repository?

[Dataflashsabot]

nthing the Android request. The PSP is also ARM and a port of Allegro is being made so fingers crossed!

[Ryan Timothy]

I have a question I need to ask someone who know how to read through the source code.
How does the engine use LightLevel from a region on a character, since a character doesn't have a LightLevel function? Does it use Tint? If so, how do you get Tint to match the LightLevel of a region?

I've tried so many different attempts to get the Tint to match the LightLevel that I'm ready to give up. Hoping someone out there knows the solution. There's a biscuit in it for you.

Edit: The only thing I can figure out is how to match the character.Tint with Region.LightLevel IF the region light level is below 100 in the room editor. In game, 50 in the room editor is actually -50 (it's value - 100).
Any region with a LightLevel higher than 100, which makes the character whiter and brighter, isn't possible to match with character.Tint.

I've made a suggestion to CJ before about having a Character.LightLevel property, perhaps one of you guys can finally add it now as a new feature.

Edit x2: The code to get the character to match via Tint if the region LightLevel is above 0 and below 100 is this (it doesn't match 100% but very very very close within 1 or 2 RGB difference):
[code]
if (theRegion.LightLevel >= -100 && theRegion.LightLevel <= 0)
  player.Tint(0, 0, 0, FloatToInt(IntToFloat(theRegion.LightLevel) / (-1.35)), 0);
[/code]

[EvilTypeGuy]

I apologise in advance for many of the hacky, tacky things I did to the AGS source code to get it to run on Linux with the initial port work.

If you see #ifdef linux or #ifndef win32 or the like, you can probably blame me :-)

I thank Chris for his willingness to let me part of the AGS dream even though I wasn't able to be for very long due to real life obligations(tm).

I sincerely hope that AGS continues on and becomes even more popular.

[timofonic]

Hello.

Are there plans to release older AGS versions? This can be interesting for compatibility with games using older versions of the engine and digital preservation purposes too.

CJ, what about releasing the entire SourceSafe repository of AGS? It can be converted to Git by using some tool like vss2git. I explained this to you previously

Regards.

[RickJ]

LibGDX seems like it may be a possible basis for an Android port (and other platforms as well).  It's Java, likely because that's the Android programming language. 

"LibGDX is a cross-platform 2D and 3D game development framework written in Java/C/C++. It's free for commercial and non-commercial use, pretty powerful and lots of fun to work with! Or at least no-one complained yet. Write your game once, deploy to Windows, Linux, Mac OSX and Android! Be brave, click the links to the right to learn more. "

http://libgdx.badlogicgames.com/
http://code.google.com/p/libgdx/

[timofonic]

LibGDX seems like it may be a possible basis for an Android port (and other platforms as well).  It's Java, likely because that's the Android programming language.  

"LibGDX is a cross-platform 2D and 3D game development framework written in Java/C/C++. It's free for commercial and non-commercial use, pretty powerful and lots of fun to work with! Or at least no-one complained yet. Write your game once, deploy to Windows, Linux, Mac OSX and Android! Be brave, click the links to the right to learn more. "

http://libgdx.badlogicgames.com/
http://code.google.com/p/libgdx/

Why using another library and even still forking AGS? I see the different ports aren't finally merged into the same codebase, making difficult to test all modificacions in different platforms and not need to merge changes from different repositories in a difficult way (just use some DVCS like Git).

Another negative point is the requiring of a Java Virtual Machine, LibGDX depends on Java. This adds more dependencies to the project, maybe not a problem in Android (Dalvik isn't exactly Java, anyway...) but it is in terms of portability and efficiency on other platforms.

Why not using something even more portable without requiring a big dependency like the Java Runtime Environment? I'm interested on the Android platform but... Why adding another dependency just for the Android port? There's tons of options out there, some of them already ready for *A LOT* wider variety of platforms and even more efficient.

If you see other interesting projects of this kind, their code is focused on portability and code reusability. Why not using a common code base and use native or a commonn library framework? Being Allegro, SDL, OpenGL, Direct2D or a backend framework for all them.

As an user and soon to be developer wannabe, I would like the AGS interpreter to have a common code base and make it easier for porters too. The more platforms AGS is, the more benefits AGS community and commercial developers will enjoy. Those developers from different worlds (commercial, hobbyist...) can help to improve AGS in a more proactive way, primarily due to stronger common interests and flow of ideas from different engines from those platforms or aiming to have a broader support of their game releases).

Are there some iniutiative likes this or we will need to wait to the full release (maybe including older releases by releasing the full Microsoft Visual SourceSafe source code repository into another repository like Git, by using a combination of automated conversion by vss2git and manual tweaking) of both the interpreter and the editor?

It's something discussed previously in certain away, I just want to keep the topic alive. I personally think the future of AGS depends on efforts like this. Are there visible project (co-)leader(s) along with Chris Jones?

[Calin Leafshade]

I agree. libGDX would be a terrible choice.

[ptiz_govorun]

what about EDGELIB?

http://www.edgelib.com/index.php?node=features

[timofonic]

what about EDGELIB?

http://www.edgelib.com/index.php?node=features

It seems quite portable, but not on most consoles (that's difficult to have all in one framework, anyway).

I see a quite negative point, the lack of source code and having to accept an EULA before downloading the "free version". The lack of source code is a problem if wanting to port it to other platfor or solve bugs.  It can be quite hypocrite to having an Open Source project like this depending on a propietary blob, anyway.

[Calin Leafshade]

Was there a reason that SDL was discounted? It seems to me to be the obvious choice since its functionality maps very closely to Allegro.

There is also iOS and Android support in the 1.3 branch.

[Alan v.Drake]

I've heard good things about SFML, but yeah, SDL is more estabilished and all.


- Alan

[timofonic]

Any news? What about releasing the code of older AGS runtime? I hope Chris Jones reads this someday...

[SchodMC]

I realized today that the source code had been released. Wonderful. So I have a question:

a) Is anyone working on a mac port? If not, I will check if I can do the job. Just what to be sure to not make the job twice
b) If a) = true may I help? (I'm working as a software developer for years, since one year I started developing on Mac OS. So knowledge won't be the Problem).

Thnx so far
SchodMC

[monkey_05_06]

Hi Schod, and welcome to the forums!

Anyone is welcome to take a crack at the source so long as they know what they're doing!

Just be sure to review the license and you should be good to go (you'll have to release it as "derived from AGS 3.2.1" or some such, but the license is pretty easy to work with).

[Calin Leafshade]

Hey Schod,

If you're an experienced mac developer then you are *very* welcome here. I suggest you take a look at this thread ( http://www.bigbluecup.com/yabb/index.php?topic=44047.msg604616#new ) and perhaps you can help us with an official port.

[SchodMC]

Hi,

well, *experienced mac developer* - some kind of. I have a lot of experiences developing Software under Windows. So C/C++ won't be the Problem. As I told, I learned developing under Mac OS using Xcode and Objective-C round about a year. So I think, I will have enough knowledge to help porting the AGS sources. However, I have enough experience to know how to learn what I need to.

Long story short: I will say "hello" in the thread you posted and take a look how I can help. See you there.

Greets,
SchodMC

P.S.: because of my rare spare time, I'm primary interested in the engine-part of the project.

[Snarky]

From Gen-Gen:

What would need to be taken into consideration for the future of AGS as a viable development platform?
* Commercial use - Wadjet Eye Games is the obvious company here; Himalaya Studios (AGDI) is another. Balancing the needs of AGS's commercial users versus the noncommercial users is not going to be easy. Being noncommercial (open source) itself means that AGS is not necessarily beholden to prioritise commercial users' needs.
* Noncommercial use - this is the majority in terms of AGS use.

There's also The-Company-Formerly-Known-as-Zombie-Cow,-Now-by-Some-Completely-Unmemorable-Name-That-I-Can't-Be-Bothered-to-Look-Up, in case they ever decide to make more Ben & Dan games.

I actually think most of the things that are important for commercial users are the same as the things that are important for noncommercial users: stability, power, multi-platform support, an efficient production pipeline, good support for collaboration. A number of free games are just about as ambitious (in most ways) as the commercial titles, so they have most of the same needs.

But of course, there will occasionally be differences in priorities. For example, savegames breaking on game updates seems to have turned into a relatively big issue for Wadjet Eye, while it's probably not such a big deal for freeware games.

Conversely, I think bringing something like the old interaction editor back; that is, a way for newbies to define game events with no/minimal coding, would really help attract new users, but it's probably not particularly useful to commercial users. (Though I've been thinking about a way to code a game interactively, as you're playing it, which might be a way to speed up development. Insane, I know.)

What other projects could AGS learn from?
* OpenSLUDGE - this uses a lower-level approach in comparison to AGS. Some of its ideas (such as storing animation data as code), might be worth looking at at least.
* Inform 7 - see how this project is managed primarily; also see if its approach of the editor as a separate program from the compiler could be of use for AGS (if it could facilitate independent editor projects for other platforms, it is at least a possibility). See if its approach regarding bug tracking and feature requesting would work for AGS.
Outreaching to these projects and others (e.g. ScummVM) would be of use. It has been suggested before that ScummVM could have support for older AGS versions included ala AGI or SCI games. Not sure if this is actually feasible, but the possibility should at least be investigated.

Wintermute is the other obvious engine to take inspiration from.
I would also look at Eclipse, Visual Studio and other IDEs, since they are designed for many of the same tasks as AGS.

The major bottlenecks for any integration with ScummVM were that Chris hasn't released the 2.7 source yet (though I'm guessing most of it is still present in the 3.x release), that the organization of future AGS development was very much unclear at the time, and licensing issues (anything that integrates with ScummVM will be GPL-only).

Priorities?
* A Project Manager being assigned for AGS as a whole - someone needs to be at the least, a go-between for the (possibly) disparate development targets within AGS and tie it all together. A figurehead is not of use here. As has been pointed out, deep technical experience is not required; that said, at least some technical knowledge of AGS (and at least basic knowledge of e.g. who would use it) would be a plus. A long-term plan for AGS is certainly essential, but the short term must not be forgotten either, as it will serve as the foundation for any long term plans going forward. Any project manager would need to be able to be trusted by all the relevant parties.
* Either using an existing source repository as the master source repo going forwards, or the creation of one - at the moment, there really does not seem to be a central source code repository for AGS. The main website has an SVN server, but access seems problematic and as a result people have set up their own, which introduces the problems of code forking and of not being shared properly.
* Assigning tasks to people dependent upon their strengths and interests (ideally)
* Bug tracker
* Promotion of the development project, recruitment of developers - separate to the promotion of AGS as a development environment in itself should be the promotion of AGS as being in development and therefore in need of developers. Recruitment should be controlled mainly by the needs of the project. Focus should be given primarily on areas of expertise lacking within the existing AGS coding team, but certainly not to exclusion.

I would add to that: managing the website and the forums day-to-day, and overseeing updates and redesigns. A lot of the bigbluecup stuff still goes only through CJ, if I understand it correctly. If he wants to maintain ultimate control, that's fine, but I think we need someone to be a bit more hands-on. (This could also potentially be broken out into a separate role, though I tend to think that it's easier to find a few people to do a lot of work than many people to do a little bit of work each... at least you're more likely to get people who'll stay committed over time that way.)

AGS STRENGTHS:
* Flexibility - AGS can do more than just graphic adventures. Increasing it's flexibility in terms of what it can do is a good idea. Whether this should be done within AGS or by facilitating plug-ins (moreso than already) is another matter.
* Community - AGS has a good community built around it, and whatever is done to AGS should bear it in mind.

AGS WEAKNESSES:
* Sprite storage - the folder idea is not a bad idea, but it is somewhat let down by the usage of numbers to represent the sprites. This means it can be hard to remember what sprite numbers are used for what. It would be very tedious to have to name every individual sprite (or even groups of sprites) too. One possible solution could be to use the original sprite filename (with sprites imported as part of an animated GIF containing the frame number). Room backdrops could also be stored in this way - it would remove the distinction between sprites and backdrops (although I don't know if this would actually be useful). Sprites wouldn't be stored in the way they are now, but as discrete images in a SpriteCache folder (ala the AudioCache folder for audio files). Some code may do things like run code if an object/character is within a range of numbers (animation states); similar could be achieved by being able to "tag" a sprite or sprites with a value (or, perhaps, allowing "arrays" of sprites).
* Room numbers - in a similar way to sprite numbers, it can be difficult to remember what room is for what while coding. There is also the issue that rooms above 300 do not save state (although how much importance that has is debatable, and the number of games this affects is certainly almost vanishingly small). Having rooms referred to with identifiers would go a long way to resolving that.
* Lack of HD mode support - this has already meant one project has moved away from AGS (The Journey Down). With HD increasingly prevalent in the gaming world, it is odd that AGS has no native HD support. This also goes for widescreen modes. There appears to have been a prevalently conservative mindset regarding widescreen or HD mode support with AGS, though there are practical concerns too (The Journey Down had considered, but ultimately abandoned, incorporating HD and/or widescreen support into AGS).
* DirectDraw/Direct3D support - supporting both of these can be problematic. Trying to change this to something else (under Windows) could equally be as difficult.

I think it's pretty clear what the main priorities are for AGS right now:

* Multi-Platform support: Get stable, well-integrated ports of the engine for Mac, Linux, and particularly the mobile systems, Android and iOS. More importantly, refactor the codebase so the engine is mostly platform-agnostic, with back-end adapters for different systems.
* Better Windows support: The whole DirectDraw/Direct3D issue, as well as resolutions, color modes, application folders, etc. It should be unacceptable for AGS to fail to run on any Windows system (XP or later).
* HD/widescreen resolutions. This might also entail optimizing certain things that AGS is slow at, and possibly relying more on hardware acceleration.

In addition, there is one longstanding bug that has become a major irritant and has to be eradicated in the next version, no excuses:
* Music skipping on room change.

When it comes to the editor, I would advocate moving to a model of file-based resources, getting rid of the internal sprite file completely (and also the same for audio, fonts, scripts and translations). The compiler should still pack it all up for the game, of course, but the editor should be reading it from the file system, and the project file should just be a list of references and property values. I think this (given a proper UI design) would really improve the workflow for many tasks. This is probably not as immediately critical as the other points on the list, though.

[Dualnames]

Seconded, about the Music Skipping. Also for the love of I don't know what, more events!

eEventRoomAfterFadeIn
eEventStartDialog
eEventEndDialog
eEventOMGLOL

EDIT: Oh, and implementing Tzachs fantastic idea about an auto-detect feature in the engine.

[monkey_05_06]

Dual, eEventEnterRoomAfterFadein can already be utilized even though on_event may not be called. You say "Bah, workarounds!" I say, why not?

Anyway, there are a lot of things that we need to do in cleaning up the code. Personally I think that refactoring should be the #1 priority for moving forward right now. We need a clean and consistent codebase if we're going to make progress without falling prey to the same problems that ail us right now. Documenting the code as we reimplement it should also be made priority, so that we have a clear understanding of what code does what.

From there we can definitely begin to address the more key features/functions of the engine that need to be implemented.

[Adamski]

In addition, there is one longstanding bug that has become a major irritant and has to be eradicated in the next version, no excuses:
* Music skipping on room change.

Hello. Just out of curiosity, and mainly because I've never experienced this on my own computer(s) and have done a lot of buggering about with music in AGS, how wide-spread is this issue and what conditions make this happen? Is there a consistent reason or is it just happening here and there for some people?

[LGM]

I was under the impression that it was something to do with the implementation of DirectX in the engine.

[JJS]

In my ports I solved the sound stuttering by introducing a new thread that handles the sound updates. The only problem is that it sometimes throws off lipsyncing by a bit. Btw, the source in my repository now compiles for Windows too, so you guys can check it out if you want.

[Snarky]

I have a fairly high-end computer (3.2 GHz AMD Phenom II X4 processor, GTX 560 graphics card and an Audigy 2 soundcard), and it happens with most games for me.

A quick test of some of the games I've been playing lately:

Chance of the Dead - no skipping
Arden's Vale - skipping
11-11-11 - no skipping
Death on Stage - skipping
Venator - skipping
Tales of Otubania - skipping (badly)
Beacon - skipping
Quasar - no skipping (surprisingly, as it's in 640x480)
Egress - skipping (badly)
Byte of the Draculator II - no skipping
DONNA - no skipping
Indy Passage of Saints - skipping

It happens with games made in 2.7 (as I recall) and 3.x versions of the engine. It skips more in high-resolution games than in 320x200/240 games, but also in some low-resolution games. Possibly it doesn't happen with MIDI, only WAV/MP3/OGG, but I'm not sure about that (is Passage of Saints MIDI or recorded?). It skips more when the screen transition is set to 'fade to black'. It doesn't matter what graphics filter (none to 4x) the game is set to use.

Supporting LGM's theory, it doesn't happen if the graphics driver is set to Direct3D, and it happens far less (not at all in most games, barely at all in Egress) if the game is set to run in a window instead of full-screen.

[JJS]

Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

[Snarky]

Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

Cool, thanks! I'll check it out when I have a chance. Is this the solution that can break lip syncing? (Which I assume means any syncing of sound and graphics, like e.g. footstep sounds.)

Conversely, I think bringing something like the old interaction editor back; that is, a way for newbies to define game events with no/minimal coding, would really help attract new users, but it's probably not particularly useful to commercial users. (Though I've been thinking about a way to code a game interactively, as you're playing it, which might be a way to speed up development. Insane, I know.)

To return to this point, would it be at all possible to implement a debug function so that when you hit an unimplemented event, the game pauses and gives you the choice to jump over to the editor and implement it live? (Presumably this would involve AGS-script running as an interpreted or JIT script rather than a precompiled language.)

[Goldmund]

DONNA - no skipping

It WAS skipping like hell,  but then I made custom fade out - fade in transitions and it stopped. The skipping is cased by fades in&outs.

[Snarky]

It definitely contributes a lot to the skipping, but I think Calin looked into it and found that it sometimes skips even without fading (or with the fading implemented in a different way).

I also do my own fading, partly because of this issue, but also because I don't like that background animations freeze during the fade in/out.

[Calin Leafshade]

Fading certainly exacebates the issue.

It seems that AGS doesnt update the buffer correctly when rooms load. If you add the fading time to that you get even more stutter.

My FMOD plugin fixed the issue (or rather worked around it) but its definitely something we need to look at as a matter of urgency.

[Adamski]

I don't use the fadein/fadeout options, so I guess that's why I've never run in to this with my 320x240 game! Very nervous about the fact that it is an issue though, and I'd really like to see it get fixed if it's a buffer problem. Sounds... straightforward enough to do so in an intarim build

Generally agree with Snarky's list of things. Currently I can grab a couple of different branches that fix different problems for me (ie, the engine build with user-defined widescreen resolutions, the 'Draconian' edition that incorporates my long standing "Fixed Scaling on D3D (and now works fine with "Smooth scaled sprites" option)" wish, now the JJS windows build that helps with the music stuttering) but it would be rather wonderful for me (and quite selfish!) if some of these fixes could be united and some sort of AGS 3.2.2beta/alpha/whatever could be put out before major restructuring surgery goes on with the source code.

[Snarky]

Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

OK, I checked it out, and it seems to work. I didn't notice the sound going out of sync, but I didn't test exhaustively. Thanks!

[uswin]

Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

Yeah, same as Snarky, I have tried your fix JJS, and so far it really does magic, The music and sfx doesn't stutter when I change room, so far not even a bit.

Usually before when I set my graphic accelerator to D3D9, the music and sfx always stuttering when I change the room. After I use your fix, the issue doesn't occur either if I set the graphic to D3D9 or Direct Draw 5. KUDOS for that !

the android port still has a sound stutter though, will post it in your thread.

Thanks.

[timofonic]

About source code licensing:

- GPL and LGPL are compatible. You can mix files under LGPL into a GPL codebase. ScummVM other projects already do this.
- GPL doesn't forbid to sell software at all, you can sell your game with a GPL runtime. Dozens of companies do that with ScummVM.
- Artistic License 2.0 is already GPL compatible too.


Anyway, you can ask this and other related stuff to the official ScummVM forum here.

From Gen-Gen:

What would need to be taken into consideration for the future of AGS as a viable development platform?
* Commercial use - Wadjet Eye Games is the obvious company here; Himalaya Studios (AGDI) is another. Balancing the needs of AGS's commercial users versus the noncommercial users is not going to be easy. Being noncommercial (open source) itself means that AGS is not necessarily beholden to prioritise commercial users' needs.
* Noncommercial use - this is the majority in terms of AGS use.

There's also The-Company-Formerly-Known-as-Zombie-Cow,-Now-by-Some-Completely-Unmemorable-Name-That-I-Can't-Be-Bothered-to-Look-Up, in case they ever decide to make more Ben & Dan games.

I actually think most of the things that are important for commercial users are the same as the things that are important for noncommercial users: stability, power, multi-platform support, an efficient production pipeline, good support for collaboration. A number of free games are just about as ambitious (in most ways) as the commercial titles, so they have most of the same needs.

But of course, there will occasionally be differences in priorities. For example, savegames breaking on game updates seems to have turned into a relatively big issue for Wadjet Eye, while it's probably not such a big deal for freeware games.

Conversely, I think bringing something like the old interaction editor back; that is, a way for newbies to define game events with no/minimal coding, would really help attract new users, but it's probably not particularly useful to commercial users. (Though I've been thinking about a way to code a game interactively, as you're playing it, which might be a way to speed up development. Insane, I know.)

What other projects could AGS learn from?
* OpenSLUDGE - this uses a lower-level approach in comparison to AGS. Some of its ideas (such as storing animation data as code), might be worth looking at at least.
* Inform 7 - see how this project is managed primarily; also see if its approach of the editor as a separate program from the compiler could be of use for AGS (if it could facilitate independent editor projects for other platforms, it is at least a possibility). See if its approach regarding bug tracking and feature requesting would work for AGS.
Outreaching to these projects and others (e.g. ScummVM) would be of use. It has been suggested before that ScummVM could have support for older AGS versions included ala AGI or SCI games. Not sure if this is actually feasible, but the possibility should at least be investigated.

Wintermute is the other obvious engine to take inspiration from.
I would also look at Eclipse, Visual Studio and other IDEs, since they are designed for many of the same tasks as AGS.

The major bottlenecks for any integration with ScummVM were that Chris hasn't released the 2.7 source yet (though I'm guessing most of it is still present in the 3.x release), that the organization of future AGS development was very much unclear at the time, and licensing issues (anything that integrates with ScummVM will be GPL-only).

Priorities?
* A Project Manager being assigned for AGS as a whole - someone needs to be at the least, a go-between for the (possibly) disparate development targets within AGS and tie it all together. A figurehead is not of use here. As has been pointed out, deep technical experience is not required; that said, at least some technical knowledge of AGS (and at least basic knowledge of e.g. who would use it) would be a plus. A long-term plan for AGS is certainly essential, but the short term must not be forgotten either, as it will serve as the foundation for any long term plans going forward. Any project manager would need to be able to be trusted by all the relevant parties.
* Either using an existing source repository as the master source repo going forwards, or the creation of one - at the moment, there really does not seem to be a central source code repository for AGS. The main website has an SVN server, but access seems problematic and as a result people have set up their own, which introduces the problems of code forking and of not being shared properly.
* Assigning tasks to people dependent upon their strengths and interests (ideally)
* Bug tracker
* Promotion of the development project, recruitment of developers - separate to the promotion of AGS as a development environment in itself should be the promotion of AGS as being in development and therefore in need of developers. Recruitment should be controlled mainly by the needs of the project. Focus should be given primarily on areas of expertise lacking within the existing AGS coding team, but certainly not to exclusion.

I would add to that: managing the website and the forums day-to-day, and overseeing updates and redesigns. A lot of the bigbluecup stuff still goes only through CJ, if I understand it correctly. If he wants to maintain ultimate control, that's fine, but I think we need someone to be a bit more hands-on. (This could also potentially be broken out into a separate role, though I tend to think that it's easier to find a few people to do a lot of work than many people to do a little bit of work each... at least you're more likely to get people who'll stay committed over time that way.)

AGS STRENGTHS:
* Flexibility - AGS can do more than just graphic adventures. Increasing it's flexibility in terms of what it can do is a good idea. Whether this should be done within AGS or by facilitating plug-ins (moreso than already) is another matter.
* Community - AGS has a good community built around it, and whatever is done to AGS should bear it in mind.

AGS WEAKNESSES:
* Sprite storage - the folder idea is not a bad idea, but it is somewhat let down by the usage of numbers to represent the sprites. This means it can be hard to remember what sprite numbers are used for what. It would be very tedious to have to name every individual sprite (or even groups of sprites) too. One possible solution could be to use the original sprite filename (with sprites imported as part of an animated GIF containing the frame number). Room backdrops could also be stored in this way - it would remove the distinction between sprites and backdrops (although I don't know if this would actually be useful). Sprites wouldn't be stored in the way they are now, but as discrete images in a SpriteCache folder (ala the AudioCache folder for audio files). Some code may do things like run code if an object/character is within a range of numbers (animation states); similar could be achieved by being able to "tag" a sprite or sprites with a value (or, perhaps, allowing "arrays" of sprites).
* Room numbers - in a similar way to sprite numbers, it can be difficult to remember what room is for what while coding. There is also the issue that rooms above 300 do not save state (although how much importance that has is debatable, and the number of games this affects is certainly almost vanishingly small). Having rooms referred to with identifiers would go a long way to resolving that.
* Lack of HD mode support - this has already meant one project has moved away from AGS (The Journey Down). With HD increasingly prevalent in the gaming world, it is odd that AGS has no native HD support. This also goes for widescreen modes. There appears to have been a prevalently conservative mindset regarding widescreen or HD mode support with AGS, though there are practical concerns too (The Journey Down had considered, but ultimately abandoned, incorporating HD and/or widescreen support into AGS).
* DirectDraw/Direct3D support - supporting both of these can be problematic. Trying to change this to something else (under Windows) could equally be as difficult.

I think it's pretty clear what the main priorities are for AGS right now:

* Multi-Platform support: Get stable, well-integrated ports of the engine for Mac, Linux, and particularly the mobile systems, Android and iOS. More importantly, refactor the codebase so the engine is mostly platform-agnostic, with back-end adapters for different systems.
* Better Windows support: The whole DirectDraw/Direct3D issue, as well as resolutions, color modes, application folders, etc. It should be unacceptable for AGS to fail to run on any Windows system (XP or later).
* HD/widescreen resolutions. This might also entail optimizing certain things that AGS is slow at, and possibly relying more on hardware acceleration.

In addition, there is one longstanding bug that has become a major irritant and has to be eradicated in the next version, no excuses:
* Music skipping on room change.

When it comes to the editor, I would advocate moving to a model of file-based resources, getting rid of the internal sprite file completely (and also the same for audio, fonts, scripts and translations). The compiler should still pack it all up for the game, of course, but the editor should be reading it from the file system, and the project file should just be a list of references and property values. I think this (given a proper UI design) would really improve the workflow for many tasks. This is probably not as immediately critical as the other points on the list, though.

[Joseph DiPerla]

I decided to participate in this source code discussion. Unfortunately I haven't read this whole discussion because I came in late and there is a lot to read. So consider this a new start to the discussion if you would like.

Anyway, here are my idea's of where we can go from here:

STEP 0: VERY IMPORTANT: Development Forums
We need to have some sort of structure for this whole process, otherwise things will get messy and we will be going nowhere with AGS. We already see several repositories for AGS on gitorious besides the official SVN and we have seen several users contribute their own versions of the Editor. This could make things confusing and one version that we like can exclude a feature we want from another build. Lets stop this now. The first thing we need is a restructuring of the Using AGS forums and the addition of the Development forum, followed by an official development team with a team leader.

How would I restructure the forums? Well for "Using AGS", I would strictly make the Technical forum an advanced user forum for feature suggestions and for how to perform advanced operations in AGS. I would then rename it to "General AGS Discussion". Remove the beginners forum. I would then add a "FAQ and Tutorials and Beginners" forum in "Using AGS" and move those topics from the plugins forum to the FAQ forum.

I would rename the "AGS Games" category to "AGS WIPS and Releases" and move the "Templates, modules and plugins" to that category.

At this point I would then add a development forum which would consist of the following:
A. - "Development Discussion" - used to discuss libraries to use, what code to add/edit/remove and other things all related to development. Public Forum.
B. - "AGS Source Code" - A place for the official team to release daily builds of AGS alpha and Beta editions and also updated archived source code. Public Forum.
C. - "Bug Fixes and issues" - a place to post all errors, bugs and things needing to be fixed. Public Forum.
D. - "Private Development Forum" - A place for the official development team to discuss how to code AGS and what official approaches to take next. Private Forum.

STEP 1: Which of the many distributions to use
There is the official SVN version but then there is the gitorious builds. Personally, JJS has developed the best build of the AGS engine and suggest using his repository. His repository works well with many OS's and his latest build is meant to build for Windows, Linux, PSP and Android from the get go. It has the essential feature that all AGSers would like: Portability.

STEP 2: Source Clean up
We should take JJS' repository and begin the clean up work on the source. Perhaps splitting up ac.cpp  and other similar files as well as improving code execution and performance. Commenting should also be added efficiently. One other thing to do is probably also use update versions of the libraries that AGS uses such as Allegro.

STEP 3: Documenting
For better control from this point on, the source code and normal conventions should be documented so that the community can expand on the development properly. This should be done at all times.

STEP 4: Testing
After cleaning the source code, it would be good to test the new engine rewrite with several games on all the OS' supported. Once thats done, we can fix the bugs and move on to the next phase of development.

STEP 5: Improving the basic framework of the engine
I know portability is a priority for many, but honestly, improving portability performance and limit issues, we need to work on the basic framework of the engine. Once thats settled, we can then begin to move on to different things. How would I improve the framework? Like so:
1. - I would begin adding support for several resolutions, in particular all those that would encourage commercial development and those needed on portable systems such Android, Windows Phone, Palm Pre, IOS, etc...
2. - Limitations. One of the many things that you hear complaints of are the limitations on rooms, objects, etc... Do all these limitations need to be removed or edited, possibly not. What limitations to take care of will depend on the community.
3. - GUI's and text parser would be next since thats main functionality of the engine.
4. - The scripting engine is something else that the community may want to edit.
5. - 64-bit inclusion.
6. - Graphical engine.
7. - File resources - how are sprites split up, etc...
8. - Misc items such as using different libraries and such.
9. - Improving the way Plugins are handled so that plugins can easily be developed for all platforms.
10. - Integration of 3D file formats, and other file formats as well as acceleration for future development. Even if 3D is not a feature to add for a while, lets atleast get the framework in there because I am certain it will come.

STEP 6: Bug checks
Needed before we move on to the next step.

STEP 7: Performance enhancements
With all the changes, performance can lag. Perhaps at this point it would be wise to look into improving performance.

STEP 8: Improving current portability
Lets face it, the current ports could always use some working on. If we port the engine to another OS before we make the current ports stable, something will eventually break. We want to make it as simple as possible to be able to take this source code and allow compilation for any of its ports with few issues.

STEP 9: Creating a very stable and current Mac Port
At this point libraries would need to be researched that would perform well with what is currently in AGS. I would suggest having the engine function from MacOS 10.2 and up would be ideal enough of a port.

STEP 10: Windows
No doubt several distributions of Windows can play adventure games, even advanced ones. However, for some reason, Windows does not play nice with itself. Meaning, something that would work for Windows XP will stop working for Windows 7. We need to stabilize AGS so that it can work for Atleast Windows 2000, Windows XP, Windows Vista, Windows 7 and the upcoming Windows 8.

STEP 11: Linux Distribution
With the various distributions of Linux, we need to either make the port universal or develop several other ports for it.

STEP 12: Bug Testing
Once again, lets make sure that nothing is broken and that the new Mac port is still functional.

STEP 13: Porting to handhelds
At this point we can begin porting to the major platforms for handhelds and phones. For instance, we already have PSP and Android. Next would need to be iOS, Windows Phone 7, Blackberry, Palm Pre WebOS, Windows Mobile, PSP Go and Nintendo DS/3DS. You might ask, is it really necessary to port to these? No. But eventually we will want to. Lets keep this in step. OpenGL ES and Phonegap would work best to port to these various other systems with minimal code change.

STEP 13b: Other ports?
At this point, I really do not feel that AGS needs to be ported to any other system than the ones above. However, some might disagree with me. Again, I strongly discourage Step 13b, but if we cant get past it, we need to consider it I guess. Some might want to port to the Nintendo Wii, Playstation 3 and X-Box. If that is necessary, I suggest the following:
A. - We can make it so that games are playable for the Nintendo Gamecube so that it can be played also on the Wii, or we can just make it for the Wii and have it also be supported for the next system that is released.
B. - Create a Playstation one version of the game engine so that it can be playable on all three systems: PS1, 2 and 3.
C. - Create a version for X-Box 360 or for the original X-Box so that it can be playable on both systems.
D. - Scrap all those options above and create a DOS version of the engine so that those systems can play adventure games on DosBox.
E. - All of the above.

STEP 14: Bug Testing again
Yes, its getting annoying, but it has to be done. Trust me. You will thank me later.

STEP 15: Error Logging feature
Looking for bugs in the future can be simplified if there can be implemented an error logging feature into the engine for every time it crashes.

STEP 16: AGS Run Game option
I like this feature and it should stay. Perhaps we can compile older versions of AGS, such as 2.5, 2.6, 2.72 and 3.0 and up so that we can run mini-games or internal-games within the updated version of AGS.

STEP 17: Seperation of Compiler and Editor
This has been long awaited for by many if not all AGS members. Basically, many have wanted to have the whole studio seperated into three components: Editor, Compiler and Engine. So at this point, we can start making improvements to the compiler so that it can be more efficient to use.
A. - The compiler should be able to compile all project files written in text, including room settings and such. It can also compile sprites and other files for our needs. This would basically work similarly to how AGAST and MAD use to work. An editor would write the project out to seperate text files and then the compiler would compile it. This would allow the building of custom editors, interaction editors and portability of the editor.
B. - Make the compiler cross platform to support Mac/Windows/Linux and then the IPad, Android Honeycomb or later, Blackberry Playbook and HP Touchpad.
C. - Create a feature in the compiler that can compile the source code to byte code and that can make the AGS sources unable to be decompiled.
D. - The ability to cross-compile.

STEP 18: Bug Testing
You heard me.

STEP 19: A revised editor
At this point we should consider what future possibilities AGS could have implemented and how the editor should reflect that, such as having 3D characters and objects and how one would edit that in the editor, Better Syntax Highlighting, a Team integration system so that users can work on a project together remotely and other things just to mention a few. However, I think the editor should also better reflect the state and portability of the current Engine. I think it should also be more modernized offering translations, panels and even a way to test the way objects and characters look in a game. And one thing that is also popular in many of today's suites: Theming. I certainly think that the AGS Editor should be Themable.

I also think that the AGS editor should be ported to other OS' as has been requested and asked for for many years now. So perhaps libraries that can be used such as JUCE and QT 4.5 or even WX Widgets should be considered. I would consider a port of the editor to the same ports of the compiler.

Two final things (Yes, I know now that some of these are suggestions) I would like to see return is the animation editor and also the interaction editor for us newbies to the C++/C# programming language.

STEP 20: Backwards compatibility
I have heard the mention of this and to be honest, I am all for this. I hated the fact that for my Simpsons Template, I had to convert it up for every version of AGS to get it to work with the latest. EG: from 2.6 to 2.72 to 3.0. I think its good to be able to have a feature which can upgrade any source version to the latest version of AGS. Lets face it, AGS will evolve constantly and eventually AGS 3.2 will not work with AGS 3.6. So to change that, we could use a system which can convert any older source to the new source. Visual Basic .net sort of used this, so why not us as well? Or another way to handle backwards compatibility is by using source scripts file extensions. For instance, a room file called room1.rm will work for AGS 4.0, however a room file that can be called room1.rm25, room1.rm26, room1.rm272 or room1.rm30 will allow for the developer to develop games using AGS 2.5, 2.6, 2.72 and 3.0 respectively.

STEP 21: Bug Testing
Yep, its important.

STEP 22: Feature additions
Now with the important stuff done and the groundwork of the future of AGS established, we can begin adding new features to it. An area I would like to see added in would be the addition of features that were done in plugins such as particles, paralax scrolling, TCPIP, etc... Then we can move on to other new features such as 3D characters and objects. Each feature should be worked on one at a time. and tested until it is working perfectly and portably. Then it should be documented in the AGS Manual along with a sample code inclusion. After that, we move on to the next feature.

STEP 23: Bug Test
Last one, I promise.

STEP 24: Demo Game
Update the Demo game to work with this version of AGS and make sure it works across all platforms. The demo game will be updated along with each new version of AGS to demonstrate the new features developed.

STEP 25: Website
Revamp it a bit to reflect the new AGS.

STEP 26: Release AGS 4.0
And the rest is history as the development team continues to improve on it and add new features and ports.

I hope this was a good write up, it only took me 3 hours to do.

[Joseph DiPerla]

I just also wanted to throw this in as well for future ports:
http://allegrogl.sourceforge.net/

[Snarky]

About source code licensing:

- GPL and LGPL are compatible. You can mix files under LGPL into a GPL codebase. ScummVM other projects already do this.
- GPL doesn't forbid to sell software at all, you can sell your game with a GPL runtime. Dozens of companies do that with ScummVM.
- Artistic License 2.0 is already GPL compatible too.

This is getting tiresome. Anyway, the point is that including GPL or LGPL code restricts us to those licenses. AGS was released under the more permissive Artistic License, and CJ explicitly wanted it to remain under permissive license. So far there's no consensus to move to GPL. I for one would oppose it.

Anyway, here are my idea's of where we can go from here:

...

I hope this was a good write up, it only took me 3 hours to do.

Have you been in the general discussion forum lately? That's where a lot of this discussion has been going down. People have been trying to pick a project manager and technical lead for the last couple of weeks, and been discussing how best to organize the project, and what the next steps should be. That's really the first step, because since CJ has apparently decided to step back from managing the development and the official repository, we need someone he can hand over to.

As for your writeup, I'd agree with many of the points, but I strongly disagree with a sequential 24-step plan. Some (most!) of these things should happen in parallel, piece by piece, some should happen in a different order, some shouldn't happen at all (or should happen, but not quite how you describe), and some other things you don't mention should. Most importantly, it would be insane to try to get it all done with the next release; there wouldn't be another AGS version for years.

About forum restructuring, it doesn't make sense to put modules and plugins in with game releases, since they're for game developer, not for players. People go to "AGS Games" to look for games to play. They go to "Using AGS" to help them make games with AGS. Two different things, two different audiences. We certainly do need a new category for AGS development, though.

[timofonic]

About source code licensing:

- GPL and LGPL are compatible. You can mix files under LGPL into a GPL codebase. ScummVM other projects already do this.
- GPL doesn't forbid to sell software at all, you can sell your game with a GPL runtime. Dozens of companies do that with ScummVM.
- Artistic License 2.0 is already GPL compatible too.

This is getting tiresome. Anyway, the point is that including GPL or LGPL code restricts us to those licenses. AGS was released under the more permissive Artistic License, and CJ explicitly wanted it to remain under permissive license. So far there's no consensus to move to GPL. I for one would oppose it.

I don't see it tiresome at all. You and a few ones are imposing subjetive opinions to the rest and just the "follow the leader" sect-like criteria is being used most of the time. I still don't read proper reasonings of the benefits of using a permissive license, for example.

Permissive to what? What's so cool about giving the BSD-like way to make closed source forks a possibility? While this may be interesting for a few companies to save costs and releasing an additional set of features unavailable to the rest (and mining a healthy competence), I see something negative for the rest of the community. And please don't show us classic replies like "our freedom to do whatever with our work" and such, that lacks proper argumenting and not a pragmatic view at all, because it's a subjetive thinking about freedom and quite related to the way propietary software developers think.

The point is that AGS is now open source, not having a proper owner, others can fork it. Despite I appreciate CJ's work, except some ports this project is having a quite slow progress since too much time.

CJ didn't explicitly disagree about a merging code to ScummVM, for example. But he didn't have a clear think about the project philosophy and AGS runtime project being part of it. He didn't show proper arguments about Artistic License 2.0 against the rest, anyway this work could be relicensed to GPL.

Anyway, Chris Jones could choose the Mozilla way: Dual GPL/AL licensing. That would benefit most of the people, but would favor the BSD syndrome too (companies forking or taking pieces of code from AGS, but the current source code quality will avoid that like none).

Anyway, I see ScummVM project has a strong technical development and progressing very positively after each release, with constant support of new games both from Reverse Engineer and source code based ports. But AGS is stagnated most of the time, with tons of chatting speculating about the future but little coding and not work about a proper development infraestructure (a good start could be hosting AGS in GitHub).

Good luck with AGS and your proper critical thinking, because project managers (are there some of those in the AGS project? Oops) and developers of the AGS project will need it A LOT. You all will not only need extremelly fanatic devotion to the project to do this hard work, but a bunch of dedicated programmers to do the hard work and that's something the AGS community lacks.

What's better? The best to the majority or the no properly reasoned philosophies about source code licenses? What's the pragmatic way? And the dogmatic one?

And people (and ScummVM Team, they are really interested on it) is still waiting for the promised older AGS runtime source code releases. Here's a comment by Eugene Sandulenko (aka Sev), a Project manager from the ScummVM Team...

As of the AGS development, anyone is welcome to come with an engine ported to our framework and according to our standards. Current AGS source code is a mess and has to be refactored heavily. This will lead to two incompatible codebases and if AGS community will continue developing original AGS engine, it will turn into an endless race for the compatibility.

Thus it was told that a feasible approach would be to port 2.x branxh which will definitely not be developed anymore. So far the sources weren't published and such discussions are pointless.

And of course, once the engine is ported to ScummVM and if the community decide to develop the engine on top of our codebase, we're fine with that, however in this case development will be ruled by ScummVM's 6 months release cycle.

I personally hope that AGS 2.x sources will be published because there is number of developers interested in tackling it, and even there is an idea to turn it into a GSoC project if we be accepted this year.

What's wrong with that?

Eugene

Anyway, here are my idea's of where we can go from here:

...

I hope this was a good write up, it only took me 3 hours to do.

Have you been in the general discussion forum lately? That's where a lot of this discussion has been going down. People have been trying to pick a project manager and technical lead for the last couple of weeks, and been discussing how best to organize the project, and what the next steps should be. That's really the first step, because since CJ has apparently decided to step back from managing the development and the official repository, we need someone he can hand over to.

As for your writeup, I'd agree with many of the points, but I strongly disagree with a sequential 24-step plan. Some (most!) of these things should happen in parallel, piece by piece, some should happen in a different order, some shouldn't happen at all (or should happen, but not quite how you describe), and some other things you don't mention should. Most importantly, it would be insane to try to get it all done with the next release; there wouldn't be another AGS version for years.

About forum restructuring, it doesn't make sense to put modules and plugins in with game releases, since they're for game developer, not for players. People go to "AGS Games" to look for games to play. They go to "Using AGS" to help them make games with AGS. Two different things, two different audiences. We certainly do need a new category for AGS development, though.

That's the bad of forums, too much chatting and difficult to follow the messages. That's why a mailing list and a dedicated IRC channel is better suited for the task.

Sorry to say it, but that's plain overthinking of planning. Too much steps, you leave little room to improvisation.

There's need of real development, too much talking and little real work. People put most of their efforts on forum posts and planning instead of real work.

About plugins, those need to be really multiplatform OR make them part of the runtime (in source code form and running as a plugin if too big). If you consent third party developers to release closed source plugins all time, no proper support of games between different platforms will be possible.

I would like to be more positive with the future of AGS, but with lack of a proactive attitude to collaborating and lack of developers... I don't see things in a positive way until that changes.

[monkey_05_06]

Tim. You keep coming here, telling us how we need to be exactly like ScummVM or else there is no way that AGS can be a successful program. The AGS engine source code could have been refactored by anybody, but no one has had the time or motivation to do it. If someone did, then we could move on with one, consistent codebase. Everyone (especially you) keeps making this assumption that we're going to refactor the code and then for some reason continue development of the existing codebase as a separate fork. That's blatantly ignorant.

AGS has only very relatively recently been open sourced. No one has taken a strong lead because 1) they didn't want to step on any toes by checking in changes that weren't approved, 2) they haven't had the time and motivation to tackle the refactoring of the code, and 3) there hasn't been any strong leadership of the project as a whole.

We are addressing those issues now. None of them have anything to do with the Artistic License. You cannot continue coming here and insulting CJ as being too ignorant to have selected the GPL. He explicitly did not want AGS to be licensed under the GPL or even the LGPL.

You yourself have said that you don't even have enough technical knowledge (that you're not a programmer) to even be able to remotely assist in tasks like refactoring the code. You clearly aren't motivating anyone to take up the task any more than they were without you, and there's a number of reasons why you would not be a good leader for the project.

So, all you're doing is coming around and spewing these inflammatory posts for your own benefit. Not for the benefit of the community. Certainly not for the benefit of AGS. Please stop trolling.

[RickJ]

I don't think Tim is trolling ; There is just a culture clash between the two groups.  Here is a thread on their forums where I've made a couple of positive suggestions to find ways of working together and the responses are typically negative such as this...

Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream with evidence of this thread being in the junk yard portion of the forum and banning people who bother to suggest about the PSP ported model as being proof that it is possible.

Right now, AGS seems to have an android port in the making but who knows how far that is coming along, also as stated above, there is a PSP ported fully finished if you want to play stuff like Six Days a Stranger on the go...

Simple answer: No, won't happen - the scumm devs have other things to attend to...

[timofonic]

Tim. You keep coming here, telling us how we need to be exactly like ScummVM or else there is no way that AGS can be a successful program. The AGS engine source code could have been refactored by anybody, but no one has had the time or motivation to do it. If someone did, then we could move on with one, consistent codebase. Everyone (especially you) keeps making this assumption that we're going to refactor the code and[/b] then for some reason continue development of the existing codebase as a separate fork[/b]. That's blatantly ignorant.

You are making wrong asumptions here. I'm going to reply to it, specially the selected parts of your message (the more relevant ones based on my personal criteria).

First of all, I didn't say about to be exactly like ScummVM. There's different options to make AGS evolve in a more solid way, but it's true some of the best practices are in the ScummVM project itself. It's an example of a well managed and maintained Open Source project, with tons of support and constant improving. The merge idea is an option, the idea of an AGS fork for running the "classic" games on ScummVM is another idea highly supported by ScummVM developers themselves too. It can be possible to do an equivalent design as of ScummVM (highly portable framework, mailing lists, a central repository in a cool place like GitHub, chat, wiki...), but that's too much time consuming and difficult to archieve.

The very problem of AGS is the lack of motivation in the computer programming side. There's lots of cool game designers, but too few computer programmers and those are busy with real life or lack of enough motivation. That's not something good to make AGS succeed, specially now CJ is practically retired from it.

What's wrong with forking? It's a very nice practice, better than staying stalled and doing nothing. If things resolve, the fork can be merged again to the official code base.

A massive refactoring is something AGS needs urgently, that's something projects like ScummVM project (you are going to hate me again some more) has quite a lot of experience.

AGS has only very relatively recently been open sourced[/b]. No one has taken a strong lead because 1) they didn't want to step on any toes by checking in changes that weren't approved[/b], 2) they haven't had the time and motivation[/b] to tackle the refactoring of the code, and 3) there hasn't been any strong leadership[/b] of the project as a whole.

I have a slightly different point of view on this.

The problem as I see it is not about open sourced being quite recently, but the contact and culture the AGS community has with Open Source.

Even Chris Jones had negative experiences with Open Source, that's why he refuse to free the code until recent.

I agree about the lack of strong leadership, that's something that should be solved ASAP. But you need to have the most skilled person with lots of skills on teamwork, not the best CJ's friend or skilled on some way.

We are addressing those issues now. None of them have anything to do with the Artistic License. You cannot continue coming here and insulting CJ[/b] as being too ignorant to have selected the GPL. He explicitly did not want AGS to be licensed under the GPL or even the LGPL[/b].

Hey, I'm not insulting CJ at all. I appreciate his work A LOT and was very happy after the open sourcing. I did see the Linux port with a total lack of manpower and this can be a great opportunity for tons of platforms and the AGS project as a whole (and game developers too).

It's OK about his dislike to GPL/LGPL or Copyleft in general, but I don't agree that this can benefit the project as a whole.

Despite CJ seems to be a great person, he has no Open/Free Source culture enough in his mind. That's something that still occours a lot in certain computer programmers not used to platforms like Linux or BSD, it takes time to understand of how the Free Software communities work.

If you want to build a proper community, you must start your organization in a very pragmatic way. You can't make decisions based on personal experiences, but seeing things as a whole and understanding the environment.

There's very solid and argumented reasons about why GPL/LGPL are (by a very big difference compared to the rest) the most popular Copyleft source code licenses. Here's a few of them in a short way.

* Free Software Foundation promotes and fights to the copyleft and their licenses have been legally very proven compared to others. They were the pioneers of the Free Software as of today, extending the hacker culture/ethic around the world.

* GPL and LGPL are licenses that promote sharing and collaborating, contrary to BSD/MIT style licenses that make easier to close the source code. They promote competition and innovation, because others can fork and the result still being copyleft too. You of course force everyone using the code to go the copyleft way, but that's something democratic because it benefit to the majority.

* The idea of private property in source code is quite weak, because there's not a owner but a bunch of people that "own" just some parts of it. This make a nicer environment for newcomers and less ego wars with other developers, because in essence nobody owns the project at all and is a meritocratic organization.

You yourself have said that you don't even have enough technical knowledge (that you're not a programmer) to even be able to remotely assist in tasks like refactoring the code. You clearly aren't motivating anyone to take up the task any more than they were without you, and there's a number of reasons why you would not be a good leader for the project[/b].

So, all you're doing is coming around and spewing these inflammatory posts for your own benefit. Not for the benefit of the community. Certainly not for the benefit of AGS. Please stop trolling.

That's a nice wrong assumption you made about me, because I don't want to be a leader at all. I can't be a leader, I'm shy and prefer other tasks in projects. I can help with other tasks, like wikis and such.

I'm not a programmer, but want to be one. Anyway, I also want to be a videogame designer too. I'm relatively good at writing and did some personal essays, short stories and articles of different topics. Of course in my native language, Spanish (my English is still too broken for it).

Why are those so negative? I only see people saying their stuff to the outside instead of hiding it. Also, most of your arguments lack of proper argumentation too.

I don't think Tim is trolling ; There is just a culture clash between the two groups.  Here is a thread on their forums where I've made a couple of positive suggestions to find ways of working together and the responses are typically negative such as this...

You are right, there's culture clash. This community is formed with people more in the artistic stuff, but less on the technical side. Other than that, people still don't get the Copyleft philosophy.

Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream with evidence of this thread being in the junk yard portion of the forum and banning people who bother to suggest about the PSP ported model as being proof that it is possible.

Right now, AGS seems to have an android port in the making but who knows how far that is coming along, also as stated above, there is a PSP ported fully finished if you want to play stuff like Six Days a Stranger on the go...

Simple answer: No, won't happen - the scumm devs have other things to attend to...

Hey, you are quoting the wrong person! That guy is a newbie and not part of ScummVM Team at all. Please be more careful the next time

Here's the proper reply to that comment from sev (Eugene Sandulenko, project leader of ScummVM and team member since 2003)...

da1writer, thanks for speaking in behalf of ScummVM team, and no, we do not ban anyone on reasons besides Rule #0.

As of the AGS development, anyone is welcome to come with an engine ported to our framework and according to our standards. Current AGS source code is a mess and has to be refactored heavily. This will lead to two incompatible codebases and if AGS community will continue developing original AGS engine, it will turn into an endless race for the compatibility.

Thus it was told that a feasible approach would be to port 2.x branxh which will definitely not be developed anymore. So far the sources weren't published and such discussions are pointless.

And of course, once the engine is ported to ScummVM and if the community decide to develop the engine on top of our codebase, we're fine with that, however in this case development will be ruled by ScummVM's 6 months release cycle.

I personally hope that AGS 2.x sources will be published because there is number of developers interested in tackling it, and even there is an idea to turn it into a GSoC project if we be accepted this year.


Eugene

few engines)

But doesn't the linux runtime also provides support for older AGS 2.x games? The authors would not have to compile it again for AGS 2.6 I think, I have read it in this topic. Doesn't the PSP Engine also support 2.x games?

My impression, admittedly based on just a few games, is that newer 2.x versions aren't always quite backwards compatible with the older ones. The games I tried were playable - even completable - with the newer runtime, but in some of them there would be some slight glitches.

I also had problems with the Linux runtime getting the colours wrong in some games. The red and blue colour components were swapped, or something like that. (I eventually got around that by compiling a custom version of the Allegro library which swapped the components back, but that was a quick and dirty hack.) I don't know if that was also related to AGS versions, or if it was just a bug in the Linux runtime, or possibly in Allegro itself.

So what do you all have to say about this? The ScummVM Team follows AGS too, and some of the most skilled people in the team do it

In short: The AGS community needs to evolve first to make AGS evolve too. ScummVM community is technically and organizatively quite superior to the AGS one. AGS community is very superior in artistic stuff (game design and such) than ScummVM community for very obvious reasons.

[RickJ]

So what do you all have to say about this? The ScummVM Team follows AGS too, and some of the most skilled people in the team do it

Tim, the two responses you quote were not responsive to my suggestion, the quote I choose was where the poster "Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream ...
Simple answer: No, won't happen - the scumm devs have other things to attend to..." and nobody disagreed with this assessment.  

I asked the folks over there to opine on the idea of documenting a game file format common to both AGS and ScummVM not to do any work.   Instead of discussing the relative merits, potential benefits, and problems all I got was pretty much "Nobody wants to work on this."   It's as if they didn't even read my post or didn't understand what I said.  

I made an earlier suggestion to help the discussion along when everyone was bickering about license incompatibilities.   I suggested that perhaps CJ choose the AL because of concerns he had for AGS users rather than concern for the AGS source code and that further discussion with CJ would be better than just ranting and speculating about his decision.

Again the responses were non-responsive.  Instead of someone stepping up and contacting CJ they instead focused on the details of a hypothetical example that was given to illustrate the process and not the outcome.  

I'm sorry Tim but interactions over there have been very negative.  It seems to me that anything I have to say is not taken seriously as if I were some kind of retard.  

Other than that, people still don't get the Copyleft philosophy.

Some do; some don't in both communities.   In the thread I referred to earlier there were a couple of beauties

Assertion: GPL prevents non-GPL code from using scumVM API
Fact: There are legal precedents where API's are found not to be copyrightable

Assertion: The scummVM documentation/website can contradict the terms of it's license agreement.
Fact: If it did in fact say that people could do X and then sue someone for doing X because doing so violates the license agreement they would be guilty of fraud and copyright abuse and because of that the license agreement would be unenforceable.

Assertion: Data used by a GPL executable must also be GPL if it is stored in the same file.  
Fact: This is true for data that exists in the GPL source code.  However, this is not true for externally generated data regardless of where it's stored especially when the function of the exe is to view/play the data.  

It should also be noted that the GPL is not adequate in all circumstances.  That's why, if you read the GPL it says that people are free to add their own clauses to the basic license.   ScummVM has itself, IMHO, made a serious error in the beginning by making it impractical to package and distribute a game file with it's runtime.  How is it impractical?  It's impractical because the GPL insists that source code and everything else needed to recreate the binary also be distributed.  This requires much more disk space, careful attention to engine versions and theoir dependencies, etc.   A clause could have been added to their license that simply allowed game files and  scummVM runtime, scummVM license.txt, one or more game files be distributed together with out the source code requirement.  Game players aren't interested in re-building the runtime.  if they were they would go to the scummVM site anyway.  So all you need is the license.txt that contains the scummVM url.  In fact the exe itself could write a duplicate of this file if for some reason it did not exist.

The Python programming language had these same kinds of issues so they created their own licnese that addressed the needs of developers and end users.   The GPL is unclear about programs that are used to write other programs.   It does not adequately address the disposition of the final product and it should.   Many people want to believe that programs written using GPL tools must also be GPL but this is an absurd outcome.  It would be the same as telling the ghost of Ernest Hemmingway that his latest novel from the here-after is owned by Microsoft because he wrote it using Word and so it is a derivative work.

That's all I have to say.  I'm sorry that the ScummVM folks have left me with such a negative impression.   I'm sure they are all (or mostly so) nice people in real life but unfortunately they are not fun to talk to on the internet.   

[Snarky]

Tim, no one is against a ScummVM compatible 2.x fork of AGS (at least, I'm not aware that anyone has voiced opposition to it). As you mention, the obstacle to it is that CJ hasn't released the source code yet. Anyway, it would mainly be up to the ScummVM guys; the main interest from the AGS side is in developing the engine further.

Similarly, I don't think anyone disagrees that ScummVM is an admirable and successful project that we could learn a lot from. I started a thread in the Adventure forum about that just a week or two ago.

The "problem" for AGS is not so much a lack of developers, I think, as a lack of organization. When CJ open-sourced the code, he indicated that he would still like to manage the development, and of course people respected that. But as it turns out he hasn't had the time, so a number of tasks that are necessary in order to transition to a more decentralized open source model haven't been taken care of. It's only recently that he said he wasn't going to be project manager going forward, and since then there's been a lot of activity to sort things out and find someone to lead development. In other words, things are just ramping up, and people are trying to solve a number of the things you talk about. And yes, that involves a lot of discussion on the forums.

Sure, the open-sourcing could have been smoother and more efficient, but most people (apart from you, apparently) understand that the key persons (present and potential future organizers) have practical constraints, and no obligation to spend their whole lives on AGS. It is what it is. Complaints and fantasy scenarios are not helpful.

The license isn't the major issue here: at most it constrains which libraries we can use. Going on and on about GPL is tiresome because it's not on the table at this time. There doesn't seem to be any clamor from anyone other than yourself to go against CJ's wishes and switch to GPL. (And that's not necessarily because we don't "get" copyleft; some of us just don't agree that it's the right choice in this case.) As you say, anyone who wants could fork the code and use the GPL license, so the only question is whether they'd have the support of the community and could attract developers. So far, no one has felt like trying.

Assertion: Data used by a GPL executable must also be GPL if it is stored in the same file.   
Fact: This is true for data that exists in the GPL source code.  However, this is not true for externally generated data regardless of where it's stored especially when the function of the exe is to view/play the data.

It should also be noted that the GPL is not adequate in all circumstances.  That's why, if you read the GPL it says that people are free to add their own clauses to the basic license.   ScummVM has itself, IMHO, made a serious error in the beginning by making it impractical to package and distribute a game file with it's runtime.  How is it impractical?  It's impractical because the GPL insists that source code and everything else needed to recreate the binary also be distributed.  This requires much more disk space, careful attention to engine versions and theoir dependencies, etc.   A clause could have been added to their license that simply allowed game files and  scummVM runtime, scummVM license.txt, one or more game files be distributed together with out the source code requirement.  Game players aren't interested in re-building the runtime.  if they were they would go to the scummVM site anyway.  So all you need is the license.txt that contains the scummVM url.  In fact the exe itself could write a duplicate of this file if for some reason it did not exist.

Rick, I agree with most of what you write, but are you certain about these two points? My understanding of the GPL is that you can at least argue that if you create and distribute a binary that contains GPL code, everything else that goes into the binary must also be released under the GPL, including any data.

Secondly, I thought the GPL notion of "distributing source" accepted "providing a URL to somewhere the source can be downloaded from" as valid. Or am I missing your point?

[RickJ]

Rick, I agree with most of what you write, but are you certain about these two points? My understanding of the GPL is that you can at least argue that if you create and distribute a binary that contains GPL code, everything else that goes into the binary must also be released under the GPL, including any data.

I believe what the GPL refers to is data required in order for the program to function properly.  They are trying to protect against someone crippling an open source program by requiring people to purchase a key for example.   I'm not 100% certain nor am I an attorney.  Who knows what kind of hay could be made of this in some court in some country?  

But let's do a little thought experiment to get some clarity.  Suppose there is a GPL media player program that display a PNG file and plays an OGG file.  The programmer was very clever and so the binary and the source don't take up much space so the source, binary, and everything can be easily distributed together.   No I come along with a fabulous photo of myself and an OGG recording of me doing the funniest ever stand-up comedy routine.  

1.  Does the GPL allow me to distribute a CD containing my copyrighted non-GPL photo and audio recording along with the GPL media player?  

2.  Now I write a little non-gpl program that invokes the player and passes the OGG and PNG filenames.  I then make it an auto-play CD that runs my invocation program.  Does that make a difference?

3.  Postage is expensive so suppose I distribute an ISO image file instead.  Does GPL allow that?   Why?  It's a  distribution of a binary file containing both gpl and non-gpl works?  

4. It could be said that the ISO isn't directly executable and thats what makes the difference.  But things like Virtualbox do this very thing with ISO files all the time.  This same functionality could be integrated into (or is already present) any modern operating system.  So this isn't a persuasive answer to #3.

5. I get tired of arguing with people and so decide to distribute the gpl-player and my non-gpl PNG and OGG files in a zip file.  Does the GPL permit this?

6. I discover there is such a thing as executable ZIP files.  So now I use I decide to make my zipfile executable so that when executed it launchs the player program and passes the OGG and PNG file names.  Is this permitted?  

IMHO, If would be absurd to say that it's not possible to mix gpl and non-gpl materials on the same disk (CD or otherwise).  I would be absurd to say that it's ok to put that stuff on a disk but it's not ok to make an ISO image.  It would be absurd to say that you couldn't put those same materials in a zip file.  It would be absurd to say that it's ok to put them in a zip file but not ok to extract the program and other files to memory and execute the program.   The law is not supposed to produce absurd results and so this is how I justify my opinion.  

Secondly, I thought the GPL notion of "distributing source" accepted "providing a URL to somewhere the source can be downloaded from" as valid. Or am I missing your point?

Your are correct about the offer to distribute.  The problem is that you have to know what version of source that was actually used to make the binary you are distributing.  You would then have to extract that version of the source from scummvm repository and post it on your website.  You would also have to get copies of the correct versions of any libraries and their source used to by that version of the binary.  You would have to do this for each platform you distribute your game for.   Now if you make another game you will have to do this all over again.  This is an insurmountable task for many AGS users.

In my hypothetical example I suggested that this requirement be fulfilled by including a license.txt file containing an offer of source code from the scummvm website with  the approriate url.  The suggestion was met with scorn and ridicule which was really uncalled for.  Again my hypothetical examples were given to illustrate the possibility of how easily some of the issues may be resolved.  

I was surprised that a benign statement paraphrasing the GPL itself provoked such vitriolic responses.  I think the so called newbie made an accurate assessment when he said "...No, won't happen - the scumm devs have other things to attend to..."

[edit]
In case anyone is wondering why I didn't argue these points on the scummvm forum and I am doing so here:

Tim kindly invited me to participate in the thread on the scummvm forum.  I took the time to register and to post a couple of what I believed to be helpful and fairly benign suggestions.  The response was very negative ("Man I don't dig them negative waves.." - Donald Sutherland, Kellys Heroes). 

I didn't argue these points overt here because:
1) I considered myself a guest on their forums. 
2) I did see how any good could come from me pointing out fallacies in their response

I took the time to relate the experience I had over there to people over here because:
1) Tim made some comments that made people over here curious about the people over there
2) I thought people over here would like to know

[timofonic]

So what do you all have to say about this? The ScummVM Team follows AGS too, and some of the most skilled people in the team do it

Tim, the two responses you quote were not responsive to my suggestion, the quote I choose was where the poster "Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream ...
Simple answer: No, won't happen - the scumm devs have other things to attend to..." and nobody disagreed with this assessment.  

I asked the folks over there to opine on the idea of documenting a game file format common to both AGS and ScummVM not to do any work.   Instead of discussing the relative merits, potential benefits, and problems all I got was pretty much "Nobody wants to work on this."   It's as if they didn't even read my post or didn't understand what I said.  

Well, that people reads lots of people and maybe missed something. You could ellaborate your idea further or talk with the developers directly at IRC over #scummvm on irc.freenode.net

The developer disagreed, as you see. Of course the forums are not so high traffic compared to others and especially junkyard (the "offtopic" forum section).



The idea seems interesting, but recompiling games is something not practical for different reasons. One is the possibility of deceased or missing people on the community, the other is the contacting effort or maybe someone can lost the original developer files.

It can be a nice idea for "AGS 4"

I made an earlier suggestion to help the discussion along when everyone was bickering about license incompatibilities.   I suggested that perhaps CJ choose the AL because of concerns he had for AGS users rather than concern for the AGS source code and that further discussion with CJ would be better than just ranting and speculating about his decision.

Again the responses were non-responsive.  Instead of someone stepping up and contacting CJ they instead focused on the details of a hypothetical example that was given to illustrate the process and not the outcome.  

They have more rewarding efforts rather than contacting people, you should see it in a broader way. Anyway, it's quite difficult to contact Chris Jones directly. There were some replies from him on the ScummVM forums, but he disappeared after that.

I agree someone should contact with Chris Jones and put the interested parties in contact with him directly. ScummVM Team wants access to the 2.x source code at least, but it would be better if releasing the entire Visual SourceSafe tree too.

I'm sorry Tim but interactions over there have been very negative.  It seems to me that anything I have to say is not taken seriously as if I were some kind of retard.  

Well, I see it in a positive way. I think you are being subjective here.

I just hope you can feel more comfortable and show your ideas there.

Other than that, people still don't get the Copyleft philosophy.

Some do; some don't in both communities.   In the thread I referred to earlier there were a couple of beauties

Assertion: GPL prevents non-GPL code from using scumVM API
Fact: There are legal precedents where API's are found not to be copyrightable

Assertion: The scummVM documentation/website can contradict the terms of it's license agreement.
Fact: If it did in fact say that people could do X and then sue someone for doing X because doing so violates the license agreement they would be guilty of fraud and copyright abuse and because of that the license agreement would be unenforceable.

Assertion: Data used by a GPL executable must also be GPL if it is stored in the same file.  
Fact: This is true for data that exists in the GPL source code.  However, this is not true for externally generated data regardless of where it's stored especially when the function of the exe is to view/play the data.  

It should also be noted that the GPL is not adequate in all circumstances.  That's why, if you read the GPL it says that people are free to add their own clauses to the basic license.   ScummVM has itself, IMHO, made a serious error in the beginning by making it impractical to package and distribute a game file with it's runtime.  How is it impractical?  It's impractical because the GPL insists that source code and everything else needed to recreate the binary also be distributed.  This requires much more disk space, careful attention to engine versions and theoir dependencies, etc.   A clause could have been added to their license that simply allowed game files and  scummVM runtime, scummVM license.txt, one or more game files be distributed together with out the source code requirement.  Game players aren't interested in re-building the runtime.  if they were they would go to the scummVM site anyway.  So all you need is the license.txt that contains the scummVM url.  In fact the exe itself could write a duplicate of this file if for some reason it did not exist.

The Python programming language had these same kinds of issues so they created their own licnese that addressed the needs of developers and end users.   The GPL is unclear about programs that are used to write other programs.   It does not adequately address the disposition of the final product and it should.   Many people want to believe that programs written using GPL tools must also be GPL but this is an absurd outcome.  It would be the same as telling the ghost of Ernest Hemmingway that his latest novel from the here-after is owned by Microsoft because he wrote it using Word and so it is a derivative work.

That's all I have to say.  I'm sorry that the ScummVM folks have left me with such a negative impression.   I'm sure they are all (or mostly so) nice people in real life but unfortunately they are not fun to talk to on the internet.  

That makes no sense at all, because mostly all games supported by ScummVM aren't just not GPL, but even propietary.

ScummVM official binaries lack the source code too, they have a text file showing the license and the program itself show it in the about section.

There are games sold for iOS that use ScummVM for the port stuff, they released the source code modifications on their website. There's no need to package the source code with the binary, that's something already discussed a zillion times since early 90s. Just provide a download link, a mail or email address for request. Anyone could mirror it over internet too

I'm sorry about your negative experience with the ScummVM folks, I see them as quite nice and supportive. Maybe you can talk them over IRC and show them your questions instead.

[eriktorbjorn]

But let's do a little thought experiment to get some clarity.  Suppose there is a GPL media player program that display a PNG file and plays an OGG file.  The programmer was very clever and so the binary and the source don't take up much space so the source, binary, and everything can be easily distributed together.   No I come along with a fabulous photo of myself and an OGG recording of me doing the funniest ever stand-up comedy routine.

I'm certainly no licensing expert, but I don't see any difference between the six cases you mention. In each of them, the player, the photo and the recording are separate works. The photo and the recording are yours to distribute, and the GPL allows you to distribute the player. You can even charge money for the whole thing, if you want to. Depending on the license of the photo and the recording, I may not be able to redistribute copies of the whole thing, but I should still be able to redistribute the player or request a copy of the source code for it.

What you describe, as I understand it, are different forms of distribution and I don't see why it would make any difference if you distribute on CD, as an ISO image, by carrier pigeon, or lovingly engraved on stone tablets. Even the self-extracting ZIP file should be ok. The GNU licensing FAQ explicitly says that an installer and the files it installs are separate works. I would guess that what the person you quoted meant is that if you embed the image and/or recording into the player itself, that could be a problem because then they would no longer separate. Your license could be violating the player's license by trying to impose additional restrictions on it.

But, as I said, I'm no expert on this.

[RickJ]

But let's do a little thought experiment to get some clarity.  Suppose there is a GPL media player program that display a PNG file and plays an OGG file.  The programmer was very clever and so the binary and the source don't take up much space so the source, binary, and everything can be easily distributed together.   No I come along with a fabulous photo of myself and an OGG recording of me doing the funniest ever stand-up comedy routine.

I'm certainly no licensing expert, but I don't see any difference between the six cases you mention. In each of them, the player, the photo and the recording are separate works. The photo and the recording are yours to distribute, and the GPL allows you to distribute the player. You can even charge money for the whole thing, if you want to. Depending on the license of the photo and the recording, I may not be able to redistribute copies of the whole thing, but I should still be able to redistribute the player or request a copy of the source code for it.

What you describe, as I understand it, are different forms of distribution and I don't see why it would make any difference if you distribute on CD, as an ISO image, by carrier pigeon, or lovingly engraved on stone tablets. Even the self-extracting ZIP file should be ok. The GNU licensing FAQ explicitly says that an installer and the files it installs are separate works. I would guess that what the person you quoted meant is that if you embed the image and/or recording into the player itself, that could be a problem because then they would no longer separate. Your license could be violating the player's license by trying to impose additional restrictions on it.

But, as I said, I'm no expert on this.

I'm glad you agree with me on this.

[eriktorbjorn]

Tim, the two responses you quote were not responsive to my suggestion, the quote I choose was where the poster "Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream ...
Simple answer: No, won't happen - the scumm devs have other things to attend to..." and nobody disagreed with this assessment.

Well, you could read it that way... but when someone makes a sweeping generalization, basically saying "the scumm team doesn't want this, and you get banned for making suggestions", and the ScummVM project lead steps in to tell that poster that "thank you for speaking on the behalf of the ScummVM team" and then proceeds to contradict him on everything he said... I can't have been the only one who read that as a polite way of telling him "who are you, and what an earth are you talking about?"

(Incidentally, he could very well be right about the "scumm team" since they would be the subset of the ScummVM team who work primarily on the SCUMM engine. But that doesn't really mean anything, does it?)

I asked the folks over there to opine on the idea of documenting a game file format common to both AGS and ScummVM not to do any work.   Instead of discussing the relative merits, potential benefits, and problems all I got was pretty much "Nobody wants to work on this."   It's as if they didn't even read my post or didn't understand what I said. 

So... instead of explaining to them that they misunderstood you (which could certainly happen when you have people from around the world using English as their lingua franca) or were getting off topic, you just went away? I did ask about something I saw as either a drawback, or a gigantic misunderstanding on my part. I guess I could always have worded it better - if it came across as confrontational, I apologize - but I never saw any reply telling me that I had misunderstood, so I forgot about it.

It seems to me that anything I have to say is not taken seriously as if I were some kind of retard.

Well, I know that I at least never intended to imply any such thing. Personally, I think you're seeing insults where none were intended.

[RickJ]

. but when someone makes a sweeping generalization, basically saying "the scumm team doesn't want this, and you get banned for making suggestions"

I never said I got banned for making suggestions.  I said that the responses were negative and did  not address what I suggested. 

(Incidentally, he could very well be right about the "scumm team" since they would be the subset of the ScummVM team who work primarily on the SCUMM engine. But that doesn't really mean anything, does it?)

Pardon my ignorance on this point.  I was unaware there was a distinction between the two.

So... instead of explaining to them that they misunderstood you (which could certainly happen when you have people from around the world using English as their lingua franca) or were getting off topic, you just went away?

I have always been taught when you are a guest in someone else's house you should obey their house rules.  It wasn't my role to keep discussions in your forum on topic nor would I have any power to do so.

Btw, my wife's native language is Spanish, I help her run a medical interpretation business, and regularly present a "Working Through an Interpreter" seminar.  So I understand and am sensitive to the language issues you raise.  Thanks for calling my attention to scummvm's diverse demographics.   

I did ask about something I saw as either a drawback, or a gigantic misunderstanding on my part. I guess I could always have worded it better - if it came across as confrontational, I apologize - but I never saw any reply telling me that I had misunderstood, so I forgot about it.

I am not sure which post you are referring to.  But I also apologize if I took something you said the wrong way.  Frankly, I didn't perceive that anyone misunderstood but rather they were just being asses for the most part.  I don't mean to insult anyone but that is what I thought of the response I got.

Well, I know that I at least never intended to imply any such thing. Personally, I think you're seeing insults where none were intended.

Thank you for saying so.  I wasn't insulted, I just didn't see how anything could be accomplished by continuing the discussion with people who seem so intransigent.   

What do suggest the two communities cooperate?

[eriktorbjorn]

I never said I got banned for making suggestions.  I said that the responses were negative and did  not address what I suggested. 

I didn't mean to imply that you did. I was thinking about the guy who replied that "the scumm team just doesn't seem to want to chase this pipe dream with evidence of this thread being in the junk yard portion of the forum and banning people who bother to suggest about the PSP ported model as being proof that it is possible." Never mind that I think he's twisting the meaning of the "junkyard" forum, I have absolutely no idea what that last part was referring to.

Pardon my ignorance on this point.  I was unaware there was a distinction between the two.

I was just being a smart-ass. Sorry about that. "SCUMM" is what we call the engine used by the LucasArts adventure games. I'm told that this may be a slight misnomer; that SCUMM was the name of the authoring system ("Script Creation Utility for Maniac Mansion") and that the engine should really be called SPUTM, but the name has stuck. Originally, that was the only game engine ScummVM supported, and while others have been added over the years, the name "ScummVM" has also stuck. So when he said "scumm team" you could interpret that as the people who work on that engine and little else, but it's probably not really what he meant.

I have always been taught when you are a guest in someone else's house you should obey their house rules.  It wasn't my role to keep discussions in your forum on topic nor would I have any power to do so.

Perhaps, but if people misunderstand the subject and there are no further posts by the original poster, people like me are probably going to assume that, "oh well, I guess he wasn't that interested after all" and start talking about other things. Of course, in a few days I'll probably have forgotten about this boart - no malice intended - so I'm not exactly practicing what I'm preaching.

Btw, my wife's native language is Spanish, I help her run a medical interpretation business, and regularly present a "Working Through an Interpreter" seminar.  So I understand and am sensitive to the language issues you raise.  Thanks for calling my attention to scummvm's diverse demographics.

Someone made a map of ScummVM developers several years ago - so it's probably badly out of date now - and back then it seemed like most of them lived in the northern half of Europe (mostly Germany), but there were still quite a few in other places and only a couple of them in English-speaking countries. Me, I'm from Sweden.

I am not sure which post you are referring to.  But I also apologize if I took something you said the wrong way.  Frankly, I didn't perceive that anyone misunderstood but rather they were just being asses for the most part.  I don't mean to insult anyone but that is what I thought of the response I got.

My concern was if a new game file format would mean that all the old games would have to be recompiled from the original game source code. (I'm not familiar with how AGS works, but I assume the games are scripted in some sort of custom programming language.) Because to me it sounded like that would mean tracking down all the authors (which could be difficult or even impossible) to get them to recompile the games (assuming the source code still exists), and if you're unlucky you may have to do it again because the translator turned out to have a bug in it.

Perhaps you meant that the translation could be made from the data files, rather than the source, but then I would think that it would be just as easy - or hard - to support the old data format directly. I assume it's pretty much frozen now anyway. I have no idea what the situation is like in the currently developed versions.

Or perhaps you meant something else entirely, and I just misunderstood.

What do suggest the two communities cooperate?

I don't know. To be honest, I haven't really followed the AGS discussion. I have a disturbingly large stack of old DOS and Windows games that I haven't played yet, and the thought of adding the AGS games on top of that is a bit daunting. Also, I wouldn't dare to presume telling the AGS developers what they should do or how they should run their project. While I'm sure there's a lot of mutual respect between the two projects, I don't know what they'd have to gain by working with ScummVM on the actively developed versions of AGS. The ScummVM framework could very well be too limited for what they are planning. There could be people within the ScummVM project who has the know-how to get AGS working on other platforms than are currently supported, but the various ScummVM ports are usually one-man projects so they may not have the time or the interest. Who knows?

I think that when people talk about adding AGS support to ScummVM, they're usually talking about the older versions. The ones which aren't developed any more. Maybe they have some problem with the official binaries (I've had some minor issues with the Linux version myself), or maybe they want to run the games on unsupported platforms. Having the ScummVM project take over maintenance of those versions (if there are developers interested in doing that, and if there are no licensing issues, etc.) could possibly be a good thing, if the AGS developers feel they'd rather concentrate on current and future versions instead. Though from what I hear, the source code for the old versions isn't publicly available at this time.

[RickJ]

Perhaps you meant that the translation could be made from the data files, rather than the source, but then I would think that it would be just as easy - or hard - to support the old data format directly. I assume it's pretty much frozen now anyway. I have no idea what the situation is like in the currently developed versions.

This is similar to what I had in mind.  AGS has done a pretty good job over the years of being able to upgrade older games to new ones just by recompiling the source.  This would seem to suggest that the data format has changed but the old functionality remains.  The one thing that comes to mind that may be problematic is the strings are handled in the 2.x branch versus the 3.x branch. 

There is some discussion over here about making some degree of separation between editor, compiler, and runtime.  I suppose "separation" could mean a lot of things.  At minimum it would mean a formal definition/documentation of the editor-compiler and compiler-engine interfaces.   So my thoughts were that if these interfaces were well designed and formally defined  it would be possible to target multiple game-engine runtimes simply by making either compilers and/or translators. 

It seems to me that scummvm, the backend engine parts, likely already has almost all of the required functionality.   The missing middle part would be the data formats and VM instructions.   If AGS and ScummVM were able to use the same definitions then AGS could have it's own native engine and could also easily target ScummVM as a runtime target.  With this kind of cooperation , between the two communities, the planned refactoring of the AGS engine could be done in a way that makes it easier to port to ScummVM

But people on the ScummVM forum have said no. no, no we can't share API or anything because all our stuff is GPL and AGS is not.  They also said they don't want to work on something that is not GPL.   

That's how I see it, where we are.  Am I wrong?

[eriktorbjorn]

This is similar to what I had in mind.  AGS has done a pretty good job over the years of being able to upgrade older games to new ones just by recompiling the source.  This would seem to suggest that the data format has changed but the old functionality remains.  The one thing that comes to mind that may be problematic is the strings are handled in the 2.x branch versus the 3.x branch.

By "the source", you mean the source of the AGS runtime, not the games themselves? I've seen some minor glitches when running old 2.x games with newer 2.x runtimes, but if it's possible to figure out the appropriate version from the game's data files that should be a fairly minor problem. (I'm not sure where this would require the converter I thought you described, though, so I must still be missing something here.)

How things are separated and handled on the AGS side is really something I can't have an opinion on, since I've only seen AGS from a player's perspective, and even then just a handful of games.

It seems to me that scummvm, the backend engine parts, likely already has almost all of the required functionality.   The missing middle part would be the data formats and VM instructions.   If AGS and ScummVM were able to use the same definitions then AGS could have it's own native engine and could also easily target ScummVM as a runtime target.  With this kind of cooperation , between the two communities, the planned refactoring of the AGS engine could be done in a way that makes it easier to port to ScummVM

The ScummVM backend is fairly simple, and there isn't really anything in it that's specific to adventure games. Each game engine has its own script interpreter, or hardcoded game logic, or whatever. Porting the AGS runtime to ScummVM would, I imagine, be mostly a matter of implementing the game detection (the parts that can identify that a set of data files is in fact an AGS game), the few functions needed for the ScummVM GUI to launch the game, replacing all the low-level bits (sound, graphics, file access ...) with calls to the ScummVM backend, use the standard decoders for sound/graphics where it's practical to do so, use the appropriate data types for 8/16/32-bit integers, make sure there are no left-over assumptions about byte ordering, etc. But I don't see  if AGS would have to make any changes to their data formats to do that, unless you really want to. After all, the various game engines in ScummVM right now have little or nothing in common in that respect.

But people on the ScummVM forum have said no. no, no we can't share API or anything because all our stuff is GPL and AGS is not.  They also said they don't want to work on something that is not GPL.

Well, any AGS-related code distributed as a part of ScummVM would - I assume - at the very least need the option to distribute it under the GPL. I don't think anyone was suggesting that AGS can't use functions like copyRectToScreen() or playRaw(), if it provides its own implementation of them. I suppose a ScummVM-compatible engine could be developed and maintained outside the ScummVM project, using a different license. It seems impractical to me, though, and licensing could possibly prevent an AGS-enabled ScummVM from being distributed. Again, I'm no expert on this and I haven't really given it much thought.

I'm not sure if I understood you correctly, and I was in a bit of a hurry even ten minutes ago so now I really need to run. 

[timofonic]

About the "universal game format" idea, there are some valid points in the following forum thread (even by Chris Jones himself)

   
About merging with ScummVM, open-source and AGS

[Endres]

The only problem is that the thread is from 2007 and I think CJ's feeling about OpenSource has changed a bit.

What is by the way the problem to make a fork of ScummVM and add AGS support to that fork? Then it could be licensed as anything, just the ScummVM part has to be still in GPL, I suppose. But does this really matter to be either in one or the other license? I mean, it is all OpenSource, so we could use it, right? Otherwise there is no point to make something open source, well, only for security reasons, but it isn't really needed. Let's look at the PSP port again!
Either the AGS Engine can be included into ScummVM, or the ScummVM can be cloned and modified to work with AGS. One of these would absolutely work even with the complicated licensing!

By the way, what is about the older scumm games anyway regarding ScummVM? I mean, the Scumm Engine is also not GPL licensed, is it?

[timofonic]

The only problem is that the thread is from 2007 and I think CJ's feeling about OpenSource has changed a bit.

Just a bit? It changed A LOT!

Anyway, that's not the point. There were some interesting points in the discussion...


What about this? It seems is something now proven to be not so true (as latest AGS is able to play games from 2.6)

This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

With me so far? Ok, now when this universal XML game language (slage-based or not) is developed by SCUMMVM, they can (nicely, of course) ask the developers of game engines (such as AGS) if they would be so kind to create an export function which exported their game to this new universal XML game language.

That's all well and good for defining inventory items, characters, etc ... but what about the game scripts? Chances are that this "universal language" would have a different set of script commands to existing systems like AGS, and probably a different scripting language as well; converting that all over would be a mammoth task and probably impossible in several places.

As scotch says, it's pretty much an impossible task.

What is by the way the problem to make a fork of ScummVM and add AGS support to that fork? Then it could be licensed as anything, just the ScummVM part has to be still in GPL, I suppose. But does this really matter to be either in one or the other license? I mean, it is all OpenSource, so we could use it, right? Otherwise there is no point to make something open source, well, only for security reasons, but it isn't really needed. Let's look at the PSP port again!
Either the AGS Engine can be included into ScummVM, or the ScummVM can be cloned and modified to work with AGS. One of these would absolutely work even with the complicated licensing!

By the way, what is about the older scumm games anyway regarding ScummVM? I mean, the Scumm Engine is also not GPL licensed, is it?

I'm not an expert or a programmer at all, but I can explain a bit on the matter.

About the relicensing ScummVM code, that's a question to the ScummVM Team. So I prefer that question to be answered by one of them.

The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.

ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)

[Endres]

This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

I think it is still the best if the games with version 2.6 upwards would work. Lower versions without a doubt do indeed need much more work as to support all later versions. The PSP Port at least also supports 2.6 games, and I don't think that there was so incredibly much effort put on this. Eventhough there could be multiple engines for different versions. For example one for AGS 2.6 - 3.x games and one for 2.0 - 2.6, and so on.

The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.

So why aren't we able to make a GPL implementation or relicensing of the AGS Engine?  
Also, I don't really see where the Artistic license disallows such inclusions in other projects which have a similar license.

ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)

Yes, Scumm was only one example I gave.

I think the most complicated task in the engine are the plugins. In the PSP port there are some of them included, but it is nearly impossible to include all plugins without enforcing an Microsoft Windows environment for the games with other than the best known plugins (snowrain, ...) in it.

[timofonic]

This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

I think it is still the best if the games with version 2.6 upwards would work. Lower versions without a doubt do indeed need much more work as to support all later versions. The PSP Port at least also supports 2.6 games, and I don't think that there was so incredibly much effort put on this. Eventhough there could be multiple engines for different versions. For example one for AGS 2.6 - 3.x games and one for 2.0 - 2.6, and so on.

It seems so, but not a proper extensive testing team has been done to know it. That's something interesting to know, so a testing from the community would be something nice to happen.

The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.

So why aren't we able to make a GPL implementation or relicensing of the AGS Engine?  
Also, I don't really see where the Artistic license disallows such inclusions in other projects which have a similar license.

I suposse there's not problem at all to GPLize the code that ends in ScummVM, especially if being targeted at classic AGS versions.

I think if you put source code using the Artistic License 2.0 into a GPL code base, the whole result ends being GPL. I'm not totally sure, so a confirmation by others can be nice

I have my own ellaborated and more than justified reasonings about Free Software and believing it's very compatible to commercial selling of games, but maybe those are contrary to the ones by members of this community. I just will just say for now that the illicit copying reason is a fallacy, because millions of people already copy and distribute commercial software without the author's permission (and I also think  the warez issue is a socioeconomical problem, not an ethical one).

ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)

Yes, Scumm was only one example I gave.

I think the most complicated task in the engine are the plugins. In the PSP port there are some of them included, but it is nearly impossible to include all plugins without enforcing an Microsoft Windows environment for the games with other than the best known plugins (snowrain, ...) in it.

Are there a list of the plugins implemented and the games using it? If not, it could be a good task for a wiki

Maybe there are lots of plugins, but those are not as widely used as it seems.

Anyway, reverse engineering those plugins can be a difficult task. Or maybe not, an expert opinion is needed here too...

[doimus]

But people on the ScummVM forum have said no. no, no we can't share API or anything because all our stuff is GPL and AGS is not.  They also said they don't want to work on something that is not GPL.    

That's how I see it, where we are.  Am I wrong?

So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.


And the only thing preventing this from happening is AGS not being GPLicensed?

Why is AGS not GPL (now that it's already open source)? What prevents AGS from being GPL? And what are the benefits and/or limitations of AGS being GPL?

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

And in any case, like it was mentioned above, what prevents ScummVM team from reverse-engineering AGS engine, just like all other angines they support?

[RickJ]

Why is AGS not GPL (now that it's already open source)? What prevents AGS from being GPL? And what are the benefits and/or limitations of AGS being GPL?

IMHO, the problem of GPL is not with AGS it's self but with the games people make with AGS.   Most of the people that come here to make games don't have their own website.  They make their game and find free file hosting somewhere which is notoriously unreliable for an number of reasons.   The requirement of them having to provide source or offering to provide source for a period of three years is a major inconvenience.   A way around this is that they be allowed to offer source from the AGS or ScummVM website.  However, when I made this this suggestion on the ScummVM forum it was met with much negativity and summarily rejected.

The other potential obstacle to GPL is confusion over the status of the game file and if it is a derivative work or not.  The game file ought to be considered a separate work don't have confidence that this is true.  The obvious solution is to add a clause in the GPL explicitly stating so.  This suggestion was also rejected by the folks on the ScummVM forum.

And in any case, like it was mentioned above, what prevents ScummVM team from reverse-engineering AGS engine, just like all other angines they support?

I believe the Artistic License allows ScummVM to take the source and make a ScummVM GPL port.  CJ has also stated so on the ScummVM forum.

[eriktorbjorn]

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

No, in fact ScummVM is already being used commercially and in accordance with the license. The Free Software Foundation (who are the ones behind the GPL) not only allow that sort of thing, they encourage it. I've never heard anyone claim that the games ScummVM have been bundled with should be affected by ScummVM's license. They're separate works that just happen to be distributed together. In some cases, the original authors have released the games as freeware, but it was never a prerequisite.

Even if the AGS compiler itself was released under the GPL (which is not what's being suggested here, but let's say it was), it wouldn't affect the license of the games created with it. Well... actually, the licensing FAQ does mention cases where it technically would, but notes that there are ways around that.

And in any case, like it was mentioned above, what prevents ScummVM team from reverse-engineering AGS engine, just like all other angines they support?

Well, I can think of several reasons that applied in the past. If we're talking reverse-engineering without access to the source code, some of them still do.

AGS used to be closed source, and reverse-engineering is a very time-consuming process. Trying to keep up with an actively developed game engine (presumably by people intimately familiar with it) just isn't very realistic. Also, because it was being actively developed I guess people were a lot more respectful of the bit in the AGS FAQ about not wanting the data file formats to be publicly known. I gather that something similar happened with the Smacker video format, where RAD Game Tools supposedly had said they didn't want that format reverse engineered. (Eventually people outside the ScummVM project did anyway, and we have taken advantage of that.)

And of course, it's a matter of manpower. Not every game engine generates the same amount of developer interest. Some linger untouched for ages, while others are updated very frequently. Even engines for well-regarded games don't always get the attention you'd think they deserve. Just look at how long it took for ResidualVM (which while not a part of ScummVM is still a close relative) to gain momentum, and that's for Grim Fandango.

[eriktorbjorn]

The requirement of them having to provide source or offering to provide source for a period of three years is a major inconvenience.   A way around this is that they be allowed to offer source from the AGS or ScummVM website.  However, when I made this this suggestion on the ScummVM forum it was met with much negativity and summarily rejected.

I've been trying to find this negativity of which you speak, but all I could see was someone responding that it depends. As I understand it, the GPL already lets you distribute copies of a program, with only its original offer to provide the source code, as long as it is done non-commercially. If so, that should handle at least some of the otherwise inconvenient cases.

I guess the expectation is that doing something commercially obligates you to do a bit more work, though personally I wouldn't care much either way unless the distributed version of ScummVM had been modified in any substantial way. (In case anyone's concerned about it, you do not have to modify ScummVM to disable game engines that you do not want to include. That's a compile-time option.)

The other potential obstacle to GPL is confusion over the status of the game file and if it is a derivative work or not.  The game file ought to be considered a separate work don't have confidence that this is true.  The obvious solution is to add a clause in the GPL explicitly stating so.  This suggestion was also rejected by the folks on the ScummVM forum.

Well, it was pointed out that changing the ScummVM license may be difficult because the copyright isn't held by any one single entity. But I honestly don't understand where the fear that the games would in any way, shape or form become derivative works of ScummVM comes from. It certainly has not been the case for any of the other games that ScummVM supports so far. Not even in the cases where we have received source code from the original developers.

[Calin Leafshade]

Products are *clearly* not deriviates works of the program used to interpret them. What are you guys *talking* about?

[RickJ]

The requirement of them having to provide source or offering to provide source for a period of three years is a major inconvenience.   A way around this is that they be allowed to offer source from the AGS or ScummVM website.  However, when I made this this suggestion on the ScummVM forum it was met with much negativity and summarily rejected.

I've been trying to find this negativity of which you speak, but all I could see was someone responding that it depends. As I understand it, the GPL already lets you distribute copies of a program, with only its original offer to provide the source code, as long as it is done non-commercially. If so, that should handle at least some of the otherwise inconvenient cases.   ..,.

You are not being responsive.  do you or do you not support the idea of allowing game developers to offer  source code directly from the ScummVM website?

The other potential obstacle to GPL is confusion over the status of the game file and if it is a derivative work or not.  The game file ought to be considered a separate work don't have confidence that this is true.  The obvious solution is to add a clause in the GPL explicitly stating so.  This suggestion was also rejected by the folks on the ScummVM forum.

Well, it was pointed out that changing the ScummVM license may be difficult because the copyright isn't held by any one single entity. But I honestly don't understand where the fear that the games would in any way, shape or form become derivative works of ScummVM comes from. It certainly has not been the case for any of the other games that ScummVM supports so far. Not even in the cases where we have received source code from the original developers.

Adding a clause to the license that explicitly re-states what it already says wouldn't be a problem unless one or more of the copyright holders has a different interpretation than you and I do.  The reluctance to add a clarifying clause indicates this may indeed be the case.

 

[eriktorbjorn]

You are not being responsive.  do you or do you not support the idea of allowing game developers to offer  source code directly from the ScummVM website?

To me personally, that seems like an appropriate way of doing it unless there have been substantial changes made to the distributed version of ScummVM. (By that, I mean substantial changes to the ScummVM source code. Adding a custom program that launches ScummVM with the appropriate command-line options or something like that wouldn't count because that too would be a separate work, governed only by its own license.) And as I said, I believe that even if someone wanted to get really anal retentive about the license (I haven't seen any signs of that myself), it still explicitly allows you to do that for non-commercial distribution.

Adding a clause to the license that explicitly re-states what it already says wouldn't be a problem unless one or more of the copyright holders has a different interpretation than you and I do.  The reluctance to add a clarifying clause indicates this may indeed be the case.

I don't know about that... I mean, I'm still hesitant about adding things to the license but that's because to me it doesn't really seem necessary. I could very well see adding it to a FAQ though.

[Snarky]

So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.

- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.

Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...

And the only thing preventing this from happening is AGS not being GPLicensed?

No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.

How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too. In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.

Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.

Why is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

What prevents AGS from being GPL?

Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.

And what are the benefits and/or limitations of AGS being GPL?

The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.

The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.

I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.

It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.

What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)

[timofonic]

So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.

Of course there's no zero worries, that's totally obvious.

OSystem's ScummVM is a framework designed to be quite portable from the practice, and even the coding guidelines in ScummVM are crafted with very high portability in mind.

The work must be done, like it happened with all the available engines in ScummVM. There's not a magical wand to get it. But the same can be said about making AGS portable and having clean code, that's A LOT of work (and maybe recreate the same level of portability can be higher than just reusing stuff like OSystem).

- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.

Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...

You seem to generalize the opinions of the ScummVM Team, anyway they have a pragmatic thinking. ScummVM is a project consisting of different subprojects, having subteams for each game engine developed. The monolithic thinking that can be applied to a project like AGS can't be applied to the modular ecosystem ScummVM is.

And you agree about Sierra AGI/SCI games. The things changed when people in the project or wanting to join offered their work on those engines. Usually the procedure in FOSS is "release early, release often" and that often means doing experimental forks like the early FreeSCI adaptation to OSystem's ScummVM.

There are people already interested in AGS into ScummVM for different reasons. Some want it for classic games (like DrMcCoy is interested in Yahztee games, for example) to be supported, and that seem something most people in both communities agree to support into ScummVM.

And the only thing preventing this from happening is AGS not being GPLicensed?

No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.

What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days.


What's so limiting about the ScummVM release cycle? They are an organized team, they release a new version each six months. I see it a quite standard way like most of the software projects out there, even better than most commercial ones with larger release cycles.

How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too.

I think you are forgeting how FOSS development works these days, using modern computer programming tools like distributed revision control systems  like Git and others like Buildbot.

* Git makes development quite easier, by making operations like forking and merging easier. Forks are a common practice in most complex projects, because they make the development of experimental stuff a lot easier. When the stuff is done to include it into the main branch, you merge the results back.

* Buildbot is a great tool to constantly test if the modified code is able to be built for different platforms, so it's a great way to check the portability and basic bugs in the code.

Each porter gets sure the engines work as intended on the platform, there's testing periods in the project too.

In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.

There's the real point! The feeling of property about a project and a community...

Contrary to what it seems to certain people, that's very relaxed in FOSS due to the Copyleft philosophy of collaboration and meritocracy. That's something not well understood to most people outside FOSS. Sense of ownership is considerated as ridiculous for true FOSS developers, because anyone can fork a project to take a different direction.

About experienced developers in AGS, I disagree. I see there are very few developers on this community, but very experienced ones in ScummVM.  Computer programming must be quite organized to get proper results and certain ideas that can be amazing to a graphics artist can be totally and ridiculous nonsense to a proper computer programmer because of solid and objective technical reasons.

ScummVM isn't a monolithic project as explained before, but a bunch of projects on a common ecosystem (using a framework named OSystem) and with a common interest in adventure game engines.

Let's go to speculate a bit about how AGS would live inside ScummVM, here's my ideas:

- AGS would have it's own set of developers, the AGS subteam. Those are developers focused on the progress of the AGS runtime, cooperating with the developers of the AGS authoring tools (the real deal of the AGS community, in my opinion).

- ScummVM would integrate the stable versions of the AGS runtime in each 1.x version, having experimental ones in separated forks that can be built automatically by using Buildbot.

- Forums  would stay the same, having a link on the ScummVM forums redirecting to the AGS ones.

- The wiki would be merged, at least the technical part of the AGS runtime.

Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.

Well, ScummVM developers managed to do difficult efforts like merging tons of engines plus rewriting ones. Some examples are AGS, SCI and Tinsel. But I agree new developers are needed to take this great effort, with volunteer work to get it done.

Refactoring with AGS alone can look easier, but the rest of the effort could be less friendly in this environment. There would be needed to prepare the project with high portability in mind if AGS want to stay relevant in these days, with lots of available platforms in the market.

Why is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.

But a proper community must follow it's own path, and not get into a religion.

What prevents AGS from being GPL?

Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.

I agree about the first part, but in the rest you are talking like a preacher.

And what are the benefits and/or limitations of AGS being GPL?

The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.

The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).

I agree about the first paragraph, there's lot of projects under GPL and that's something objetively verificable. It's quite common open source programmers prefer Copyleft over BSD/MIT style licenses, because it makes their code to be always available and not closed sourced by other individual or company/corporation (like Microsoft and Apple does most of the time, for example).

It hasn't been an obstacle to many commercial developers and publishers already using ScummVM. So what's the problem?

Even ID Software releases their games as GPL too, but the game data still being propietary and need to be bought.

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.

Excuse me, but what's wrong with giving back the code to the community? You receive it, then give something back!

Nobody can stop giving away an unauthorized copy, even by using samizdat-like laws like SOPA and ACTA. That relies on the personal ethic of the individual, not on the software license itself.

I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.

It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.

I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.

It's quite possible to extract the games of the already available games from the AGS bundle, that's not a problem at all.

About using an installed or bundler, that's quite possible to do without breaking the GPL. It has been done with other projects.

What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)

That's something that need to be discussed, as Steam is closed source and having a strict license. I would like to know the opinion of other people on this matter, it looks a quite interesting situation to know for me.

[timofonic]

So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.

Of course there's no zero worries, that's totally obvious.

OSystem's ScummVM is a framework designed to be quite portable from the practice, and even the coding guidelines in ScummVM are crafted with very high portability in mind.

The work must be done, like it happened with all the available engines in ScummVM. There's not a magical wand to get it. But the same can be said about making AGS portable and having clean code, that's A LOT of work (and maybe recreate the same level of portability can be higher than just reusing stuff like OSystem).

- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.

Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...

You seem to generalize the opinions of the ScummVM Team, anyway they have a pragmatic thinking. ScummVM is a project consisting of different subprojects, having subteams for each game engine developed. The monolithic thinking that can be applied to a project like AGS can't be applied to the modular ecosystem ScummVM is.

And you agree about Sierra AGI/SCI games. The things changed when people in the project or wanting to join offered their work on those engines. Usually the procedure in FOSS is "release early, release often" and that often means doing experimental forks like the early FreeSCI adaptation to OSystem's ScummVM.

There are people already interested in AGS into ScummVM for different reasons. Some want it for classic games (like DrMcCoy is interested in Yahztee games, for example) to be supported, and that seem something most people in both communities agree to support into ScummVM.

And the only thing preventing this from happening is AGS not being GPLicensed?

No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.

What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days...

What's so limiting about the ScummVM release cycle? They are an organized team, they release a new version each six months. I see it a quite standard way like most of the software projects out there, even better than most commercial ones with usually larger release cycles.

How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too.

I think you are forgeting how FOSS development works these days, using modern computer programming tools like distributed revision control systems  like Git and others like Buildbot.

* Git makes development quite easier, by making operations like forking and merging easier. Forks are a common practice in most complex projects, because they make the development of experimental stuff a lot easier. When the stuff is done to include it into the main branch, you merge the results back.

* Buildbot is a great tool to constantly test if the modified code is able to be built for different platforms, so it's a great way to check the portability and basic bugs in the code.

Each porter gets sure the engines work as intended on the platform, there's testing periods in the project too.

In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.

There's the real point! The feeling of property about a project and a community...

Contrary to what it seems to certain people, that's very relaxed in FOSS due to the Copyleft philosophy of collaboration and meritocracy. That's something not well understood to most people outside FOSS. Sense of ownership is considerated as ridiculous for true FOSS developers, because anyone can fork a project to take a different direction.

About experienced developers in AGS, I disagree. I see there are very few developers on this community, but very experienced ones in ScummVM.  Computer programming must be quite organized to get proper results and certain ideas that can be amazing to a graphics artist can be totally and ridiculous nonsense to a proper computer programmer because of solid and objective technical reasons.

ScummVM isn't a monolithic project as explained before, but a bunch of projects on a common ecosystem (using a framework named OSystem) and with a common interest in adventure game engines.

Let's go to speculate a bit about how AGS would live inside ScummVM, here's my ideas:

- AGS would have it's own set of developers, the AGS subteam. Those are developers focused on the progress of the AGS runtime, cooperating with the developers of the AGS authoring tools (the real deal of the AGS community, in my opinion).

- ScummVM would integrate the stable versions of the AGS runtime in each 1.x version, having experimental ones in separated forks that can be built automatically by using Buildbot.

- Forums  would stay the same, having a link on the ScummVM forums redirecting to the AGS ones.

- At least the information related to the technical part of the AGS runtime would be merged into the Wiki.

Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.

Well, ScummVM developers managed to do difficult efforts like merging tons of engines plus rewriting ones. Some examples are AGI, SCI and Tinsel. But I agree new developers are needed to take this great effort, with volunteer work to get it done.

Refactoring with AGS alone can look easier because of a more progressive way, but the rest of the effort could be less friendly in this environment. There would be needed to prepare the project with high portability in mind if AGS wants to stay relevant in these days, with lots of available platforms in the market.

Anyway, the source code of the AGS runtime is quite rusty and needs a proper refactoring. It's one of the very common mistakes of one-man projects, they lack of coding standards because that person already understands the whole codebase (but that fails in a bigger group, where someone focus more on certain parts of of the projects than others).

Why is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.

But a proper community must follow it's own path, and not get into a religion.

What prevents AGS from being GPL?

Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.

I agree about the first part, but in the rest you are talking like a preacher.

And what are the benefits and/or limitations of AGS being GPL?

The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.

The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).

I agree about the first paragraph, there's lot of projects under GPL and that's something objetively verificable. It's quite common open source programmers prefer Copyleft over BSD/MIT style licenses, because it makes their code to be always available and not closed sourced by other individual or company/corporation (like Microsoft and Apple does most of the time, for example).

It hasn't been an obstacle to many commercial developers and publishers already using ScummVM. So what's the problem?

Even ID Software releases their games as GPL too, but the game data still being propietary and need to be bought.

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.

Excuse me, but what's wrong with giving back the code to the community? You receive it, then give something back!

Nobody can stop giving away an unauthorized copy, even by using samizdat-like laws like SOPA and ACTA or by an extreme evolved Big Brother approach from the wet dreams of british/american/chinese/iran governments. That relies on the personal ethic of the individual, not on the software license itself.

I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.

It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.

I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.

It's quite possible to extract the games of the already available games from the AGS bundle, that's not a problem at all.

About using an installed or bundler, that's quite possible to do without breaking the GPL. It has been done with other projects.

What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)

That's something that need to be discussed, as Steam is closed source and having a strict license. I would like to know the opinion of other people on this matter, it looks a quite interesting situation to know for me.

[Sslaxx]

Can we stop with the open source zealotry, please, Timfonic. You are not helping. CJ has explicitly set a license and that should be honoured. With all the complications that could be thrown up by adopting the GPL or LGPL, we should either stick with the Artistic License v2, or adopt a MIT/ZLib/PNG license.

[timofonic]

Can we stop with the open source zealotry, please, Timfonic. You are not helping. CJ has explicitly set a license and that should be honoured. With all the complications that could be thrown up by adopting the GPL or LGPL, we should either stick with the Artistic License v2, or adopt a MIT/ZLib/PNG license.

You are not helping with your attitude too. Please avoid insults or negativity under certain point of views.

[Sslaxx]

Everything has a time and place.

I'd be happy to see game developers releasing the source code to their games, but I am implacably opposed to forcing this upon them. You will scare off potential commercial developers from using AGS if this were so, and whilst AGS is primarily hobbyist those commercial developers should not be ignored.

Regardless of CJ's dogma (or not) with wanting more "permissive" licenses than the (L)GPL used, it is a pragmatic move to do so. As has been noted in other threads, the use of the GPL/LGPL can cause problems with other software libraries (primarily commercial ones). And while yes, most "permissive" licenses like MIT allow for closed source forks, the GPL does not exactly forbid this either (for internal/private use, for example).

[Snarky]

Sooo much tedious! timofonic, 90% of what you write could be condensed to "GPL rules!!111" We all know your stance by now, and each post is just wearing down more and more of our patience.

Why is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.

But a proper community must follow it's own path, and not get into a religion.

Being pragmatic means recognizing the situation as it is. Would it be good for AGS to fork off the project into a GPL branch, going against CJ's express wish and potentially splitting the community? Even if one were to prefer GPL in principle, I think the pragmatic answer would have to be a clear no.

Incidentally, the ScummVM devs also seem inclined to defer to the wishes of the creator and developer of AGS in this matter, even if the license would technically allow them to ignore him.

I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.

Releasing your own code as GPL is completely different from relying on GPL-licensed code by others. You can do whatever you like with your own work (for instance, ID could use the game code they released under GPL in other projects without releasing the source for those derived works), but once you use someone else's code under the GPL license, you are subject to all its terms.

[monkey_05_06]

timofonic's posts are becoming more and more derogatory, more and more patronizing, and more and more flagrantly inflammatory. Whether or not he's doing it on purpose, he is constantly spewing the same information, adding new bits here and there. His responses are not generating useful discussion that are in any way relevant to this thread (this is the thread about the release of the source code, arguments over what the GPL is are completely irrelevant).

I think that people are beginning to realize where my frustration was coming from, and reaching the same conclusions themselves. We have usefully discussed all that timofonic has presently brought up for discussion, and until he brings something new to the table, there isn't much point chasing him around in circles.

[Alan v.Drake]

You guys are so verbose. If you used even only half the energy you pour into these threads to clean the source code, we'd be already done.

- Alan

[Snarky]

Hah! You haven't reckoned with how slow of a coder I am.

Honestly, even if I devoted all forum time to improving the AGS code, I'd probably still be reading the current version of the source, and possibly looking into various libraries we could build on top of.

[doimus]

Regardless of CJ's dogma (or not) with wanting more "permissive" licenses than the (L)GPL used, it is a pragmatic move to do so. As has been noted in other threads, the use of the GPL/LGPL can cause problems with other software libraries (primarily commercial ones). And while yes, most "permissive" licenses like MIT allow for closed source forks, the GPL does not exactly forbid this either (for internal/private use, for example).

Thanks for this clarification. That's one pretty serious limitation of GPL-ing the code, IMO.

[fuzzie]

Being pragmatic means recognizing the situation as it is. Would it be good for AGS to fork off the project into a GPL branch, going against CJ's express wish and potentially splitting the community? Even if one were to prefer GPL in principle, I think the pragmatic answer would have to be a clear no.

Incidentally, the ScummVM devs also seem inclined to defer to the wishes of the creator and developer of AGS in this matter, even if the license would technically allow them to ignore him.

This whole thread is a bit confusing to us ScummVM devs - to be clear, we'd love to support the existing AGS games in ScummVM. That has been a very common request from many, many users for a long time. If there had been a code release which supported all the older AGS games we'd have *jumped* on it. Perhaps at some point we'll take a look at the ports which added support for older games and see if we can't make something of that code ourselves.

But it seems clear from this thread that *ongoing* development of AGS within ScummVM is probably not what many AGS devs want - even ignoring the licensing worries, our priorities are compatibility with old games, portability (i.e. games should run on all platforms), longer-term release cycles to make sure all the platforms stay in sync, etc. Obviously things like new features for engines would always be less important to us, because that's not what our project is about. (And bundling the game data into a single platform-specific binary along with ScummVM is probably not something we'd be spectacularly happy about either, because of portability concerns - again ignoring any licensing issues.)

(And about the licensing: There are commercial releases of games bundled with ScummVM on things like the iOS app store. Their game data hasn't magically become GPLed. But we can't add clauses to our license without the permission of (long-gone) contributors, even if we wanted to. Some clarification in our FAQ is obviously an option if our general view is unclear to people, as already suggested long ago in the ScummVM forums.)

[DrMcCoy]

I'd be happy to see game developers releasing the source code to their games, but I am implacably opposed to forcing this upon them.

This is a completely seperate issue. No one is talking about that.
Making the engine GPL does not have anything to do with the games it runs.
It doesn't have any implications on the experience of an AGS game.
It doesn't have any implications on the marketability or profitability of a commercial AGS game.
In short, this is a non-issue.

Now, if we're talking engine plugins, like the various graphical effects plugins I've seen AGS 2.x games use, they would fall under the GPL. And that's, in my eyes, a very good thing.
Because a) Not being able to run 2.x games when you don't use Windows because the game needs some rain drop effect DLL is insane
and b) This doesn't limit you as a game (and plugin) creator in the slightest, while enriching the community. I.e. you're giving back to the community => everyone wins

And while yes, most "permissive" licenses like MIT allow for closed source forks

That's actually the ideological difference between MIT-style and GPL-compatible licenses: The GPL forces you, when you enhance a project you use, to give back that enhancement to the community; while MIT-style licenses allow you to keep those enhancements to yourself.

Quite frankly, I think the latter is selfish and should be discouraged; therefore I like the GPL.

Interestingly enough, I don't think there's any legal problems with just taking the AL-licensed code CJ released and just re-/dual-licensing it to the GPL. Any enhancements made upon that codebase would then be only GPL-licensed. That's why I for one am quite surprised that CJ chose such a permissive license when he's not that happy about its consequences.
Yet again, IANAL, so I might be talking bullshit here.

Note that again, we are not talking about AGS games.

the GPL does not exactly forbid this either (for internal/private use, for example).

IANAL, but I think I remember reading that the GPL prohibits that too (or rather, says that you have to share any useful enhancements). It's not really enforceable, sure, but as soon as any of it leaks into the wild, you have a problem.
[EDIT: Or apparently, I'm wrong there.]


Now, to extend a bit on what fuzzie said: You are also confusing two mostly different issues:
1) Adding an engine for 3.x+ games to ScummVM
2) Adding an engine to ScummVM that supports legacy 2.x games

Only 1) would theoretically necessitate moving AGS development into ScummVM, since it's, I assume, still actively developed and we really wouldn't like playing catch-up with a complety seperate AGS repo. Doing that would be boring, extremely stupid and a massive time-waster.

As for 2): I've seen the source CJ released, which I assume is 3.x. From what I've seen by digging through it, it's missing stuff to load 2.x games, so the current 3.x branch doesn't run 2.x games anymore, making them already disjunct. At least 2) should be relatively uncontroversial then, no?
Provided, that is, that the 2.x sources get released and there's motivated people working on it. Because quite frankly, the already released sources are horrible and the whole thing would need a completely clean rewrite before it's anywhere near readable and portable.

[monkey_05_06]

Now, if we're talking engine plugins, like the various graphical effects plugins I've seen AGS 2.x games use, they would fall under the GPL.
...
This doesn't limit you as a game (and plugin) creator in the slightest, while enriching the community. I.e. you're giving back to the community => everyone wins

False. If the AGS plugin is based on a closed-source API then it makes sense for the AGS plugin to be closed source. Case in point: AGSteam. The Steamworks API is currently very restrictive in its licensing. To release an open-source AGSteam plugin would be to either break the license of the Steamworks API (and thereby infringe on the copyright of Valve), or to strip out the references to the Steamworks API, leaving the plugin source in a useless state. Every single user-exposed function of the AGSteam plugin relies in some degree on the Steamworks API.

Requiring AGS plugins to be licensed under the GPL or a compatible license would be, as you say, "insane".

[DrMcCoy]

If the AGS plugin is based on a closed-source API then it makes sense for the AGS plugin to be closed source. Case in point: AGSteam. The Steamworks API is currently very restrictive in its licensing.

I see that as a (very severly) fault with the Steamworks API, then.
For this particular example, there's also Open Steamworks (with some limitations).

Regardless, if you want to keep them closed, that still doesn't necessarily preclude the GPL for the engine.
The question then is whether the plugin is, like game scripts, mere data; depending on how it's called. The plugin would then ship with the game and not ScummVM (and the game would hopefully have a way to check whether a plugin is available and have a fallback).
Theoretically, there's also apparently the possibility to add an extenting clause to the ScummVM license saying that proprietary (AGS) plugins are allowed. From what I heard in a FOSDEM talk a few days ago, The GIMP did that with their license for their plugins.
I myself am not particularily a fan of that option, though.

[monkey_05_06]

Regarding Open Steamworks, "some limitations" includes:

Furthermore, you do not get access to the Steamworks backend. You cannot create achievements, register a game, or do other backend related activities.

That entirely negates the purpose and usefulness of the AGSteam plugin. The entire existence of said plugin is to provide an intermediate API between the closed Steamworks API and AGS itself. The AGSteam API is proprietary of MonkeyMoto Productions, Inc. and is freely available, and as a separate work does not fall under any of the licensing terms of the Steamworks API. The AGSteam plugin itself however, does directly utilize the Steamworks API, and out of necessity is therefore closed-source.

If I stripped out the ability to set achievements and stats, then sure, I could use the Open Steamworks API, but AGSteam would be utterly pointless as it wouldn't do anything. I'm not saying that Open Steamworks itself is incapable of doing anything, but presently achievements and stats are the stated purpose of AGSteam.

[qptain Nemo]

The Steamworks API is currently very restrictive in its licensing. To release an open-source AGSteam plugin would be to either break the license of the Steamworks API (and thereby infringe on the copyright of Valve)

Would you kindly link to the aforementioned license?

[Snarky]

I see that as a (very severly) fault with the Steamworks API, then.

Well, Steam has no obligation to be open source, and can impose whatever legally valid licensing conditions they want, just as GPL can. If the two sets of conditions are incompatible, the fault is equally on each side.

I'd agree that it's troubling that a closed, proprietary distribution system, marketplace, etc. should have such market power, but that's just how it is, and commercial developers need to take it into account. If using AGS means they can't take advantage of basic Steam features like achievements, that's obviously a major handicap.

[qptain Nemo]

Btw even if what you say about Steamworks licensing is true, isn't it strikingly obvious that GPL programs can dynamically link to any proprietary dlls so if AGS was under GPL there'd be no problem at all with that a closed source ags plugin would exist that provides the necessary steam interactions?

[timofonic]

I see that as a (very severly) fault with the Steamworks API, then.

Well, Steam has no obligation to be open source, and can impose whatever legally valid licensing conditions they want, just as GPL can. If the two sets of conditions are incompatible, the fault is equally on each side.

I'd agree that it's troubling that a closed, proprietary distribution system, marketplace, etc. should have such market power, but that's just how it is, and commercial developers need to take it into account. If using AGS means they can't take advantage of basic Steam features like achievements, that's obviously a major handicap.

Well, could you please provide a link of the Steamworks API license[u/] or whatever that forbids that from Valve? Dosbox is used by many games distributed by Steam and Dosbox is GPL itself, like id Software games.

http://games.slashdot.org/story/07/08/05/1951243/id-and-valve-may-be-violating-gpl
http://www.eurogamer.net/articles/id-sorts-gpl-steam-issue

Anyway, aren't there other alternatives besides making AGS to access the Steamworks API? Like writing the relevant information to a file and a watchdog wrapper looking at it to send it by using the Steamworks API, for example. This can be a more generic solution that would require less specific code added to the game engine to maintain, too.

[monkey_05_06]

Tim, your "watchdog wrapper" would be a derivative work, and therefore need to be licensed under GPL.

According to GNU, plugins are considered derivative works, or part of the same software. Either way, the GPL would require plugins to be GPL.

If AGS was to adopt the GPL, closed-source plugins (that interact with the engine) would be a copyright violation.

When I was saying "Steamworks API" I was specifically referring to the exposed methods of the Steamworks SDK. Just because they're exposed though doesn't mean that they're publicly available. Valve has very little to no documentation of the API as of this writing that is publicly available. If you want access to the full API documentation, you have to get access to the SDK. That means you have to sign a Non-Disclosure Agreement and a Source Code Addendum. Physically sign it.

If anyone wants to link to the Steamworks API license and prove me wrong, I wouldn't mind opening the source to AGSteam. Everything I have seen and read though prevents me from doing so, under obligation of the aforementioned NDA.

It would be possible to add an exclusion to the license of the AGS to allow closed-source plugins, however it would then negate the identification of AGS as "Free" software, according to GNU. It would make the entire move to the GPL pointless. So, even if AGS moved to the GPL, it would have to do so in such a fashion as to defeat the entire purpose of why we did so; or else closed-source plugins would forever be banned from legal (public) usage with AGS.

[DrMcCoy]

If I stripped out the ability to set achievements and stats, then sure, I could use the Open Steamworks API, but AGSteam would be utterly pointless as it wouldn't do anything.

YMMV, but I'd argue that achievements themselves are pointless...

Well, Steam has no obligation to be open source

The whole of Steam wouldn't need to be open. Only the API; the part the communicates with the steam client and server.

and can impose whatever legally valid licensing conditions they want

Sure. And I'm just as free to feel that this is a valid point to not use such systems and to discourage others from using it. As you describe it, Steam, thanks to the restrictive license of the Steamworks API, automatically shuts out GPL (and related) licensed works. I find that highly troubling.

I'd agree that it's troubling that a closed, proprietary distribution system, marketplace, etc. should have such market power, but that's just how it is, and commercial developers need to take it into account.

Call me naive, but I never liked that defeatist attitude of "It's how it is and we can't change it".
I'd argue that an openly communicated boycott because of these restrictions would be anything but a handicap.
Also, like I said, I never got the point of achievements anyway. I play games for the story and occasionally the addictive gameplay; I don't need no flashing "X points of damage dealt" (or even worse "Passed Chapter II of linear game Foobar").


Regardless of all that, like I said, if the plugin instead ship with the game as game data, the point could still be made that they are akin to game scripts and therefore not subject to the engine's GPL license.
Still, I certainly don't like that idea. Apart from my idealogical views, pure-binary plugins are a major damper for portability.

(Just to throw yet another fancy idea into the room: A different plugin system could work similar to a JavaVM, with the plugins being portable compiled bytecode that's interpreted by the engine, with some limited hooks to call platform-dependant libraries for things like the Steamworks API. This would give us the "best" of both worlds, with plugins still portable and yet closed and distributed with the games. Of course, this would add another new language a plugin-author needs to get accustomed to and add to the size of the engine).

According to GNU, plugins are considered derivative works, or part of the same software. Either way, the GPL would require plugins to be GPL.

No, not necessarily. The default lawyer answer to that would be "Maybe". I.e. it depends on the case, the court, etc..
Like I said, I just heard a talk about that on the FOSDEM in Brussels a few days ago, with actual lawyers present. The showcase there was The GIMP, which actually has a plugin system and has an extension in their GPL license to explicitely allow closed / proprietary plugins.

If AGS was to adopt the GPL, closed-source plugins (that interact with the engine) would be a copyright violation.

No, wrong, see The GIMP.

It would be possible to add an exclusion to the license of the AGS to allow closed-source plugins, however it would then negate the identification of AGS as "Free" software, according to GNU. It would make the entire move to the GPL pointless.

No, wrong, see The GIMP. The GIMP is still free software, while still allowing proprietary plugins. I can't say that I myself am too happy about it; I'd rather have all plugins free. I can understand their reasoning though, which is that they don't want to drive away plugin creators that depend on patented and therefore non-free information, because that would only hinder the adoption of The GIMP if you always have to explain to others why a certain function that's common in, say, Photoshop isn't available. The core functionality, that what maybe most people care about, however still remains free software.

[qptain Nemo]

According to GNU, plugins are considered derivative works, or part of the same software. Either way, the GPL would require plugins to be GPL.

Well. FSF are being a bit vague and contradictory on it. For instance:
http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Valve has very little to no documentation of the API as of this writing that is publicly available.

Docs don't equal API itself. The only relevant thing here is the API's own license and whether Valve allow you to expose code that interacts with it or not.
It'd be rather strange if they forbade you specifically that though.

If anyone wants to link to the Steamworks API license and prove me wrong, I wouldn't mind opening the source to AGSteam.

Why does anybody have to check if your claim has any grounds or not? You're simply admitting that it doesn't if you ask that.

[Ogon]

What is the benefit of GPL for anyone? It is just more restrictive. Artistic License 2.0 can do the same, while allowing everyone to do even more, like more permissive closed-source usage which draws some players in (e.g. companies) that would probably not use AGS otherwise and might also contribute something at some point. Shouldn't we all be happy?

Why can't ScummVM sublicense the AGS code parts with Artistic License 2.0 (and keep that licensing in their repository), while still distributing the whole ScummVM under the terms of the GPL? Since the two licenses are compatible, that should be a total non-issue. I don't see the point with all those shouts about AGS -> GPL.

If the merge was done in an intelligent way, pure Artistic License AGS could even stay operative with the old Windows-focussed frontend, and optionally compile/run with the GPL'ed ScummVM.

[monkey_05_06]

If anyone wants to link to the Steamworks API license and prove me wrong, I wouldn't mind opening the source to AGSteam.

Why does anybody have to check if your claim has any grounds or not? You're simply admitting that it doesn't if you ask that.

My claim is based entirely on the fact that to the best of my knowledge, such an expressly written license for the API specifically does not exist. Nowhere have I been able to find that the API has a separate license from the SDK. Nowhere.

So you can drop the crap and stop trying to make me look like an idiot. If someone who actually has the ability to prove me wrong wants to, I welcome that, but until then you're just being flagrantly inflammatory for the sake of trying to piss me off.

I have specifically referenced the following pages, as well as every single page that they link to.

http://www.steampowered.com/steamworks/FAQ.php
https://partner.steamgames.com/

The Wikipedia entry on Steam indicates the Steamworks API as being "freely available" but that's open to interpretation of the term "free". I didn't pay anything in order to sign the NDA with Valve, so I freely gained access to the Steamworks SDK.

I'm not saying that a license on the Steamworks API (separate from that of the Steamworks SDK) does not exist. I'm saying that I have never seen any form of it, and what I have seen is directly indicative that it does not. Again, I welcome anyone who has found what I overlooked, but you can't discount my claim just because my searches (including Googling!) have utterly and completely failed to yield the results that you are demanding from me. I have documented the background of my claim. If you want to disprove it, the burden now falls to you.

Regarding the GPL, GNU is very explicitly clear that derivative works, especially in the form of plugins that interact with the original software, are required to either be a) licensed under the GPL, or b) an exception must be added to the license of the software, which invalidates the "Free" status of the software. GNU does distinguish that system libraries are an exception to this, specifically meaning those libraries which are part of the operating system or environment. AGS plugins do not remotely fit the definition of system libraries.

If GIMP has an exclusion in their version of the GPL which allows closed-source libraries to be used, then per the GNU definition, it does not meet the requirements to be classified as "Free" software. This isn't just some unbased claim, this is information that is explicitly published by GNU.

[Monsieur OUXX]

ScummVM integration

Licenses issues left aside, I think there should be a completely separate thread about ScummVM, because I've got the feeling that :
1) Not everybody understands what ScummVM is, from a programmer's perspective
2) Not everybody understands  what it can actually do
3) Everybody has a different idea of how AGS should be integrated with it / how AGS games should run on it.

So what do you think? Separate thread? At least to clarify the expectations and abilities?

[Snarky]

Whether or not GIMP is free software, isn't the point that if we wanted to integrate with ScummVM, we'd have to adopt the GPL as is, without any additional clauses? Is anyone advocating moving to GPL even if we keep the project separate from ScummVM?

As for the whole games-wouldn't-be-affected-by-the-license thing, as I've said I think that depends on details of the implementation, and that the way AGS currently works, they would. I agree that there are ways to implement it where they wouldn't be, though.

I've argued that we should move features out of the core engine and into user-editable modules that are not in principle any different from the script modules for e.g. the LucasArts UI. (So instead of coming with an engine-hardcoded Sierra-like UI, AGS wouldn't have a built-in UI but instead multiple modules you could choose from.) Since these modules would integrate directly with games, they couldn't/shouldn't be GPL. It would take careful consideration to decide what should be an engine feature and what should be part of the module library, particularly if initially implementing it in the engine (and licensed under the GPL) would mean it couldn't later be moved into a module (and licensed under a more permissive license).

[Alan v.Drake]

As far as I know plugins do not have to be GPLed as long as you can prove that the application can run fine without them. Of course if this apply also to the compiled game is unclear to me.


- Alan

[Endres]

(Just to throw yet another fancy idea into the room: A different plugin system could work similar to a JavaVM, with the plugins being portable compiled bytecode that's interpreted by the engine, with some limited hooks to call platform-dependant libraries for things like the Steamworks API. This would give us the "best" of both worlds, with plugins still portable and yet closed and distributed with the games. Of course, this would add another new language a plugin-author needs to get accustomed to and add to the size of the engine).

This would be really an idea beyond the pale. I mean, the concept sounds nice, but the coding effort would be way too high. For this, and many other "problems" I may refer to the PSP port of AGS again. We only need to add the most used plugins by either asking for the source code or rewriting them - look at how the author of the PSP version ported it. This would lead to that we have to implement every possible plugin into the engine (either or not hard coded), but this is not a very huge problem, as most plugins could be rewritten simply using the (I suppose) existing ScummVM functions. Of course this can not be very easily done for every single plugin, thinking about not only SteamWorks. But I think that this is a minor problem we could think about later on, as we firstly need to get plugin-free games working. Use of plugins is explicitly not encouraged for portability, but I think this is also stated in the FAQ. What about just giving the user a popup saying "we can't support this game because the specific plugin can't be executed on this system"?
The application would run fine without plugins, if the game does not need any special plugins. Same for the compiled game. If the engine works usually for every game, but not for one specific, then I don't think that this could be a reason not to develop an implementation which only works with nearly any game. I don't get why this should depend on how to license it.

And the "legacy" 2.x issue doesn't really exist, I suppose, as all games from 2.6 can be played with the PSP port.

Now I think even GPL is not a problem. The engine doesn't have to be open source at all to get a working engine that can use game data and do things with it. It's all about data processing. ScummVM would only take the compiled ac2game data or strip it off the executable and processes it. So the ScummVM part is really independent to the original AGS Engine. Otherwise ScummVM would not be able to support any other engine anyway.

We should not think too much about exceptions. What we need is a development team that would really work on creating such an implementation. If I had more free time, I would think about reading up on ScummVM development.

[qptain Nemo]

Is anyone advocating moving to GPL even if we keep the project separate from ScummVM?

Whether the main fork of AGS is GPLed or not would change very little, but I do believe that in the given circumstances GPL would provide healthier developing atmosphere because any decisions made by the Official Elite Dev Team would have less severe impacts and would be easier to fix in case anything goes awry as well as would reduce the need to struggle forever over doubtful decisions, simplify experimentation, let be closer to the community (which everybody holds in high regard here, right?) and many other things.
And I'm not even talking about all the useful GPLed code that will be available to freely use with AGS, that benefit should be rather obvious.

[RickJ]

The GPL in it's vanillia form is ill suited to the class of applications that are intended to be used to create or run other programs.   The reason for this is it's broad definition of derivative and combined works.  There is a considerable amount controversy and unsettled legal questions surrounding the issue even among copyright attorneys as evidenced by these two articles from the International Free and open Source law Review

• Software Interactions and the GNU General Public License
  
• Working Paper on the Legal Implication of Certain Forms of Software Interactions (a.k.a. linking)
  
  

We in the AGS community have expressed our concerns and have enumerated at least three specific concerns we would have distributing our games with a ScummVM binary.  In stead of our concerns being addressed in a serious manner we are told that we don't get copyleft and that if we just adopted GPL everything would be just fine.  

You need to get this straight in your heads:  The Artistic License was chosen by CJ who listened to our needs and working slavishly of over the past 15 years to satisfy those needs.  We are extremely loyal and grateful to him. The particular license he chose may not protect the AGS source code as well as some other license could but it does seem to satisfy the needs of the people who use AGS to make their games.  Everybody here respects this decision and support it's continued use.  Further, nobody here would benefit from a GPL'd Ags.

Further, you on the one hand say "Well game files are clearly not derivative works".  But on the other hand you won't say so on the license, thus reserving the right to file future lawsuits over the issue.  

You also say on the one hand, "Well it would be all right with us if people downloaded source from the ScummVM website and so game develpers wouldn't have to supply source" but on the other hand you again refuse to say so on the license.  Again preserving the right to file future lawsuits.

You keep reassuring us that your license already addresses these issues and that we don't have to worry.  But then you say you can't add a clarification clause to the license that explicitly makes the very same assertions because that would change the meaning of the license.  Which is it?

You also say that you don't know who all the contributors are or how to contact them and that's why you can't add clarification to the license.  However, if the clause that is added does not change the meaning of the license as you have said above then it wouldn't be necessary to contact everyone, Right?.   It ought to be a no brainer!  

Unless of course you have reason to believe that some contributors may have a different interpretation of the license than you do.  In this case any of the known or unknown contributors could surface at any time and file a lawsuit over these issues.  

So what you are really doing is encouraging people to engage in behavior that you have reason to believe would be understood by one or more ScummVM contributors to violate the ScummVM license and htier copyright.  Isn't that correct?

IMHO, this position is intellectually dishonest and morally reprehensible.  

Realistically, a ScummVM port of AGS runtime(s) would be of limited benefit to AGS game designers if it couldn't be confidently and easily distributed with their games.  

I'm out of this Cheese Shop!  Cheers...

[wjp]

Hi all,

Let me try to summarize ScummVM's license viewpoint.

ScummVM is licensed under the (unmodified) GPL, and has to stay that way,
simply because it is infeasible to contact all right holders and their
estates/heirs for a license change.

Many people have agreed to release their code under the specific text of the
GPL, and we can't just change that text retroactively, even if we personally
feel it is only a clarification and not a change with any legal effect.

We're more than willing to clarify our personal viewpoints on any issues you
raise in our FAQ, and in fact have a first draft about one such issue on our
development mailing list already.

However, ultimately of course the choice to distribute ScummVM is up to any
individual who wants to do so. If you or they feel uncomfortable with our
license, then so be it. If you feel you need clarification on legal issues, I
suggest contacting a lawyer, or possibly the Software Freedom Law Center may be
able to assist. Several commercial game releases include ScummVM however, and
their publishers have likely done their legal due diligence.

If you wish to twist our reasoning, that is also your choice, but I do not much
appreciate being called intellectually dishonest and morally reprehensible.

We would still potentially be interested in AGS support in ScummVM, but would prefer
discussions about this to be civil and constructive. The current directionless
bickering here seems to be neither.


Sincerely,
Willem Jan, ScummVM core developer

[bicilotti]

I will dive in this 12 pages topic to say that the discussion is getting out of our hand.
Artistic License 2.0 and GPLv2+ are compatible and I am sure that there is a technical solution to offer AGS games via SCUMMVM without having them open sourced (I will use the layman term 'repackaging' even if the question is slightly more complex).

Alas Rick, ScummVMers cannot change the license (because that would mean tracking down every single contributor and ask for her/his permission. You can't add words or clauses because you feel they are just clarifying a license, you just can't. it would be a legal abomination and in first place adding more 'restrictions' (again, layman term) is forbidden by the license itself.

The question raised by Monkey is interesting and requires attention (still the Gordian knot which would only mean such tainted games would not run on ScummVM, saving both parties from being tainted by the other).

The point of this post is: we can play the lawyers that we are not or discuss how technical could help us to be better prepared to solve those problems (whichever license will be chosen).