Very initial thought: the headers on some of the files need to be altered to reflect the change of licensing.
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.
Well this should be an interesting decade! :=
------ 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]
Is the compiler included in this release?
I assume thats included in the ags.native assembly but i dont see the code for it.
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:
Well spotted, I've checked in a fix for this so please try again with the latest version.Good job, that solved it!
#include "afxres.h"for:#define IDC_STATIC -1
#include <windows.h>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.
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.
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...Post here for now, I'd say.
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?
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?
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
Warning 11 warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library acwin
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
Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."
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
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:This can easily be removed by going to the project properties, Linker/Input/IgnoreSpecificLibrary and adding ,LIBCMT to the end.QuoteWarning 11 warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library acwin
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
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.
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?
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.
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. :P
Engine/acchars.cpp:696: error: cast from ‘short int*’ to ‘int’ loses precision
‘AL_CONST’ was not declared in this scope
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.
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.
I did get this error:Code: [Select]Engine/acchars.cpp:696: error: cast from ‘short int*’ to ‘int’ loses precision
And I get this error in ac.cpp:51Code: [Select]‘AL_CONST’ was not declared in this scope
#ifndef AL_CONST
#define AL_CONST const
#endif
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.
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.
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.
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?
Yeah, I'd say integrate 2.72 into ScummVM and let the 3.x branch alone.
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 :P
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?
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
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.
Lot's of chatting, typical of forums. Are there people already working on this? I'm curious about it...Well, are you?
I think that's why he said it.ScummVM is meant to play old junkIt's funny that you say this
[...]
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.
[...]
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..."
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
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:
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
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:
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?
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?
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?
Has anyone else looked into getting this to work on 64bit platforms yet?
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.
- a working code::blocks project for AGS 3.2.1 with updated notes in the project
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. ;)
QuoteSome 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.
QuoteOk. 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.Quote- 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!
Ooops, I didn't realise SDL doesn't yet support iPhone or Android.
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.
QuoteThere'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.
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 may well provide the source to legacy versions at a later date.
QuoteIs 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.
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.
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.
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
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/
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.
"_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_aspect_ratio(int, int, int*, int*), _maincoltable ,
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)
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.Looking forward to it!
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.
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.Looking forward to it!
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.
Done, my port is now imported into http://gitorious.org/ags (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.
Done, my port is now imported into http://gitorious.org/ags (http://gitorious.org/ags).
Feel free to do anything you like with it, and add to the wiki.
Do you believe in magic?
While I think that is awesome doesn't it contravene the license?
Specifically the "You may not distribute this code" part?
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.
Does this mean i need to make a mac and linux version of Nimbus? D:
Do you believe in magic?
(http://www.losmunditos.com/images/ags/bdm_mac.png)
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...
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).
- built-in video support using gstreamer framework (for the Mac guys, have a look here (http://codeanticode.wordpress.com/2009/04/03/gstreamer-installer-for-macosx/) and here for the binaries (http://itee.uq.edu.au/~davel/gstreamer/). For gstreamer on windows, look here (http://code.google.com/p/ossbuild/))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 platformsWould be nice. But isn't audio working already?
- create ags plugin support on linux & macI 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.
- built-in video support using gstreamer framework (for the Mac guys, have a look here (http://codeanticode.wordpress.com/2009/04/03/gstreamer-installer-for-macosx/) and here for the binaries (http://itee.uq.edu.au/~davel/gstreamer/). For gstreamer on windows, look here (http://code.google.com/p/ossbuild/))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 platformsWould be nice. But isn't audio working already?
- create ags plugin support on linux & macI 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.
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.
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
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
for allegro, i downloaded the 4.4 source and compiled.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
I have also problems with Ubuntu. I first tried under 64 bit, but now I'm trying with 32 bit.YES! =)
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?
Most internalized libraries are fixed by now, with the notable exception of AGS overriding allegro’s pack_fopen.
This can probably not be fixed without getting a patch into Allegro
-Wl,-wrap,pack_fopenIf you look it up you'll find the technique I used...Heheheh... actually, it CAN be fixed without getting a patch into Allegro... at least for the linux build.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.
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: [Select]-Wl,-wrap,pack_fopenIf you look it up you'll find the technique I used...
I tried compile Editor under Ubuntu (10.10) using mono.
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().
Heheheh... actually, it CAN be fixed without getting a patch into Allegro... at least for the linux build.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.
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: [Select]-Wl,-wrap,pack_fopenIf you look it up you'll find the technique I used...
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.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
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)
#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;
}Separatoreven when load_wav internally calls pack_fopen.
Wrapper_function
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]
#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
Nevermind. I'm rewriting the MP3 code without using ALMP3.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?
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: [Select]#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
(None of those three Engine/ files were touched by psp-patch)
if (gfxDriver->UsesMemoryBackBuffer()) // make sure all borders are cleared
gfxDriver->ClearRectangle(0, 0, final_scrn_wid - 1, final_scrn_hit - 1, NULL);
part of display_switch_in. I'm not even sure it makes sense at all.With this modification game (Kq3Redux) is not segfaultting on ARM, but it just ends. Debugger says: Program exited with code 0133.Code: [Select]if (gfxDriver->UsesMemoryBackBuffer()) // make sure all borders are cleared
gfxDriver->ClearRectangle(0, 0, final_scrn_wid - 1, final_scrn_hit - 1, NULL);
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).
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
Hmm... this thread is getting cluttered with people trying to build the source for windows, linux, mac, ... I propose using a section in the AGS wiki to coördinate this stuff, rather than lots of people setting up their own project site.
#7 0x0007bab4 in quit (quitmsg=0x21a3c0 "|You have exited.")So something is triggering a normal exit.
at ags_maemo/Engine/ac.cpp:9341
#8 0x000a0af8 in QuitGame (dialog=0) at ags_maemo/Engine/ac.cpp:17995
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.adventuregamestudio.co.uk: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.
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;
}
I believe several people are currently working on 3.2.2 using a CVS, yes.
if (theRegion.LightLevel >= -100 && theRegion.LightLevel <= 0)
player.Tint(0, 0, 0, FloatToInt(IntToFloat(theRegion.LightLevel) / (-1.35)), 0);
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/
what about EDGELIB?
http://www.edgelib.com/index.php?node=features (http://www.edgelib.com/index.php?node=features)
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.
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.
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.
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.
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.
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.
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.)
DONNA - no skipping
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.
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.
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.)QuoteWhat 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).QuotePriorities?
* 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.)QuoteAGS 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.
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, 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. :)
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...Quote from: sevAs 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?
EugeneAnyway, 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.
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...
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.
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.
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].
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.
I don't think Tim is trolling ; There is just a culture clash between the two groups. Here is a thread (http://forums.scummvm.org/viewtopic.php?t=9775&start=60) 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...
QuoteWell 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...
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
Quote from: EndresBut 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 itTim, 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 ...
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: 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.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?
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.
QuoteSo 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 itTim, 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.
QuoteOther 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 (http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq) 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. :=
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 glad you agree with me on this.QuoteBut 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.
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.
It seems to me that anything I have to say is not taken seriously as if I were some kind of retard.
. 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.
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.
I never said I got banned for making suggestions. I said that the responses were negative and did not address what I suggested.
Pardon my ignorance on this point. I was unaware there was a distinction between the two.
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 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.
What do suggest the two communities cooperate?
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.
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.
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.
The only problem is that the thread is from 2007 and I think CJ's feeling about OpenSource has changed a bit.
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.
QuoteWith 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 (http://jjs.at/software/ags.html) 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?
This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.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.
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.
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 (http://www.gnu.org/licenses/license-list.html#ArtisticLicense2) of the AGS Engine? ;)
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.
This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.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.
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.
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 (http://www.gnu.org/licenses/license-list.html#ArtisticLicense2) 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.
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?
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.
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.
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?
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.
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 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. ..,.
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.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.
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?
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.
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?
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.
Quote- 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...
What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days.QuoteAnd 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.
QuoteWhy 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.
QuoteWhat 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.
QuoteAnd 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).
QuoteDoes 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.)
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.
Quote- 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...
What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days...QuoteAnd 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.
QuoteWhy 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.
QuoteWhat 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.
QuoteAnd 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).
QuoteDoes 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.)
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.
QuoteWhy 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.
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.
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).
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'd be happy to see game developers releasing the source code to their games, but I am implacably opposed to forcing this upon them.
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).
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
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.
Furthermore, you do not get access to the Steamworks backend. You cannot create achievements, register a game, or do other backend related activities.
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?
I see that as a (very severly) fault with the Steamworks API, then.
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.
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.
Well, Steam has no obligation to be open source
and can impose whatever legally valid licensing conditions they want
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.
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.
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.
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:
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.
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.
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.
ScummVM integration
(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"?
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.
Do we have a formal spec anywhere for the AGS VM and datafile formats? If so, someone could put together a small (PD-licensed?) reference application to show how it goes together and the ScummVM team could work from that. As no AGS code would be used in that case, license (in)compatibility would not be a concern, although it'd naturally take longer to get a working implementation together.This will not work. Nobody would work from the specs, it will give no benefit to anyone. Developing whole engine basing on the documentation is an enormous project and will definitely bring pain and incompatibilities.
Am I to understand that you recommend making AGS *require* the ScummVM binaries? And then game developers distribute ScummVM with their game? If that were the case wouldnt the engine need to be *entirely* rewritten to conform with ScummVMs system? How would engine development continue? Would it need to be controlled by the ScummVM team or would development still rest with us?
However, if the GPL is a problem due to things like Steam plugins, then someone would have to reimplement a new (non-GPL) version of the ScummVM framework code in order to distribute a non-GPLed AGS runtime, which would probably be a lot of work. Something only the AGS community could decide.
Is that really an issue? Surely if scripting code within a games data files is not subject to the GPL then neither are plugins bundled with a game. There's no in-kind difference between the two.
Am I to understand that you recommend making AGS *require* the ScummVM binaries? And then game developers distribute ScummVM with their game? If that were the case wouldnt the engine need to be *entirely* rewritten to conform with ScummVMs system? How would engine development continue? Would it need to be controlled by the ScummVM team or would development still rest with us?AGS badly requires maintainability. Working with 29k+ lines of code ac.cpp file is hardly possible. Thus, it has to be refactored/rewritten, whatever.
Game assets are not bound by the executable license. ....
Putting several assets with separate licenses into a single archive or on same media does not affect their licenses. GPL governs only software source code which is linked (in terms of object linker, used by compilers) to it statically. I.e. your GPLed Linux libraries could be dynamically linked with your proprietary executable without it being affected by GPL. If you have to link statically, there is LGPL license, specifically for that purpose.
If an AGS game will be using ScummVM, it will have links to our site as well as relevant copyright statements in the About dialog. Since our site contains full source, that is enough for complying to the license. Again, this is valid only for the cases when there are no modifications to ScummVM source code.QuoteSev, thanks for acknowledging the issues and offering a practical solution. Putting this in a FAQ is
a little weak. Perhaps, in addition, there could be a separate "GPL Compliance" text file that would/could accompany any distributions. It could include similar to the above statements and others as well as the offer of source code and the relevant URLs.Quote from: sevNow, considering that currently AGS is embedding the compiled game scripts into a single game executable, this is a bit problematic. ... You still can consider this as a blob under different license, but purist communities like Debian require source code for everything which is in the executables. Nevertheless splitting out game data from executable is not a technical problem at all, not to mention, that keeping them together is a technical problem since it is not portable at all.QuoteUp until recently AGS did produce a separate game file in addition to the combined executable and a separate game file isn't a technical problem at all or a foreign concept to AGSers. However, at times the combined exe is convenient and useful. Perhaps the licensing issues could be sorted out in the above mentioned compliance document and the remaining technical issues addressed by a "Project options/configurations" in the editor where the user could setup multiple compile/build targets. It would then be possible to specify which files are to be produced for each target.Quote from: sevScummVM is GPL, but some parts of it are dual-licensed. So could be the AGS engine, i.e. it could stay as GPL/APL, but outside of ScummVM framework somebody has to implement all required APIs.QuoteSomething like this has been in my mind also but based on what everyone was saying it just didn't seem possible or worth the mention. Thanks for bringing sanity into the discussion. ;)Quote from: sevCurrent AGS code is of low level quality, and is practically impossible to maintain and develop by any team beyond single person, which was admitted by Chris himself, and has obvious reasons to be such.I think everyone is in agreement on this point. There are recent discusions here about the need to refactor and how to proceed.Quote from: sev... Thus, if some team is arranged on either side, e.g. AGS for developing 3.x or ScummVM for porting the engine, it must be refactored. Then, depending on the consensus we either will have 2 incompatible code bases, or still single one shared by both communities.It was previously said on the ScummVM forum that nobody would be interested to do this and that nothing from ScummVM. not even the API, could be used in AGS/APL. So I welcome this proposal as I suspect most (if not all) in the AGS community do.
The proposed solution... My suggestion is that since you're looking towards portability, you are welcome to use our code infrastructure since it is proven in 10 years of the project history as reliable and comfortable to work with. You keep AGS engine under APL, which is forward-compatible with GPL, i.e. it could be published under APL as separate entity, and under GPL as part of ScummVM distribution. You are getting nice framework with tons of convenient and portable utility classes, and most probably also number of ScummVM developers, interested in developing the engine.
Also, I would highly recommend monkey_05_06 as a sort of technical liaison between the two groups. I have no idea if he would be interested in such a role however he does possess excellent deep diving skills and is extremely tenacious when it comes to understanding, in great detail, how things work. He and I often disagree in our technical discussions but I can say that he always makes good points and usually tells me things I didn't know or hadn't thought about. He also seems quite interested in the re-factoring of the engine.Quote from: sevAs of the proprietary plugins, we already have plugin subsytem with dynamic linking, so as soon as those plugins are not using our code, they could be closed source. Of course, this subsystem has to be extended a bit since these days it supports loading of whole engines, not some parts of them.With a few exceptions, most of the plugins written for AGS ended up being closed source likely because nobody ever thought to make them open source or suggested that plugin authors consider making them open source.
Is the plugin system something that could live in an APLish AGS?Quote from: sevI welcome everyone to start our discussion from this very message. Alternatively the moderators could consider splitting it out from this thread and starting from the scratch.Eugene, again many thanks for the generous helping of sanity. I look forward to future discussions.
Sev, thanks for acknowledging the issues and offering a practical solution. Putting this in a FAQ isIn fact it is business of the game authors. They have to provide accompanying licenses as part of their distributions. To comply with GPL, they have to provide ScummVM license, and next to it they should put a license which explicitly deals with their game assets. This should make everything clear in every instance. Putting it now on the ScummVM site would be pointless. Consider the freeware game distributions available from scummvm.org website. All of them contain separate license.
a little weak. Perhaps, in addition, there could be a separate "GPL Compliance" text file that would/could accompany any distributions. It could include similar to the above statements and others as well as the offer of source code and the relevant URLs.
Up until recently AGS did produce a separate game file in addition to the combined executable and a separate game file isn't a technical problem at all or a foreign concept to AGSers. However, at times the combined exe is convenient and useful. Perhaps the licensing issues could be sorted out in the above mentioned compliance document and the remaining technical issues addressed by a "Project options/configurations" in the editor where the user could setup multiple compile/build targets. It would then be possible to specify which files are to be produced for each target.Again, you cannot combine executables with the data in a portable fashion with current approaches, e.g. the data is generated by AGS compiler and then glued together with the interpreter. There are technical possibilities to it, such as generating inline data in form of .cpp files and then recompiling the engine, but stop thinking in Windows terms if you are gearing towards the portability.
It was previously said on the ScummVM forum that nobody would be interested to do this and that nothing from ScummVM. not even the API, could be used in AGS/APL. So I welcome this proposal as I suspect most (if not all) in the AGS community do.If you are basing your assumptions on post by da1writer (http://forums.scummvm.org/viewtopic.php?p=71110), I have no clue who he is, where he is coming from, and why on earth he has guts to speak in behalf of our team. Nothing like this was expressed by ScummVM team members. Please correct me if I'm wrong.
Also, I would highly recommend monkey_05_06 as a sort of technical liaison between the two groups.That's good to know.
With a few exceptions, most of the plugins written for AGS ended up being closed source likely because nobody ever thought to make them open source or suggested that plugin authors consider making them open source.This subsytem is already in place, and since it is platform-dependent, it lives in backends part of our code. This would not help to have it as part of the engine, since it will have to rely on our code. What needs to be done, is that this interface extended a bit, relevant .h files dual licensed under APL, and then the proprietary plugins can use it and will be picked up by the engine and linked run-time. GPL license issues, e.g. no static linking is allowed are avoided. And after all, it is ScummVM team who potentially can sue people violating our rights, so everything could be arranged beforehand. In an unlikely case when our current plugin headers cannot be dual licensed because some developer who was involved in writing parts of it is not available anymore, the relevant comparatively small code could be rewritten from the scratch and dual licensed on purpose.
Is the plugin system something that could live in an APLish AGS?
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.