Author Topic: Initial AGS Engine Source Code release  (Read 88945 times)

Snarky

  • Global Moderator
  • Private Insultant
    • I can help with proof reading
    • I can help with translating
Re: Initial AGS Engine Source Code release
« Reply #160 on: 16 Jan 2012, 16:21 »
Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

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

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

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

Goldmund

  • Mittens Baronet
  • Be a man, goddamit!!! Grow some 'stache!!!!
    • I can help with translating
    • I can help with voice acting
Re: Initial AGS Engine Source Code release
« Reply #161 on: 17 Jan 2012, 09:31 »
DONNA - no skipping

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

Snarky

  • Global Moderator
  • Private Insultant
    • I can help with proof reading
    • I can help with translating
Re: Initial AGS Engine Source Code release
« Reply #162 on: 17 Jan 2012, 12:03 »
It definitely contributes a lot to the skipping, but I think Calin looked into it and found that it sometimes skips even without fading (or with the fading implemented in a different way).

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

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on a game that won an AGS Award!
    •  
    • Calin Leafshade worked on a game that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #163 on: 17 Jan 2012, 14:20 »
Fading certainly exacebates the issue.

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

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

Adamski

  • Mittens Viscount
  • Subaquatic Battle Weapon
Re: Initial AGS Engine Source Code release
« Reply #164 on: 17 Jan 2012, 19:09 »
I don't use the fadein/fadeout options, so I guess that's why I've never run in to this with my 320x240 game! Very nervous about the fact that it is an issue though, and I'd really like to see it get fixed if it's a buffer problem. Sounds... straightforward enough to do so in an intarim build :)

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

Snarky

  • Global Moderator
  • Private Insultant
    • I can help with proof reading
    • I can help with translating
Re: Initial AGS Engine Source Code release
« Reply #165 on: 19 Jan 2012, 09:04 »
Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

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

Re: Initial AGS Engine Source Code release
« Reply #166 on: 23 Jan 2012, 05:37 »
Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.

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

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

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

Thanks.

Re: Initial AGS Engine Source Code release
« Reply #167 on: 23 Jan 2012, 21:56 »


About source code licensing:

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


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

From Gen-Gen:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Joseph DiPerla

  • Joseph DiPerla, Adventure Game Creator Wannabe!
    • I can help with backgrounds
    • I can help with characters
    • I can help with play testing
    • I can help with story design
    • I can help with translating
    • I can help with voice acting
    • I can help with web design
Re: Initial AGS Engine Source Code release
« Reply #168 on: 24 Jan 2012, 04:02 »
I decided to participate in this source code discussion. Unfortunately I haven't read this whole discussion because I came in late and there is a lot to read. So consider this a new start to the discussion if you would like.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

STEP 18: Bug Testing
You heard me.

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

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

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

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

STEP 21: Bug Testing
Yep, its important.

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

STEP 23: Bug Test
Last one, I promise.

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

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

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

I hope this was a good write up, it only took me 3 hours to do. :)
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

Joseph DiPerla

  • Joseph DiPerla, Adventure Game Creator Wannabe!
    • I can help with backgrounds
    • I can help with characters
    • I can help with play testing
    • I can help with story design
    • I can help with translating
    • I can help with voice acting
    • I can help with web design
Re: Initial AGS Engine Source Code release
« Reply #169 on: 24 Jan 2012, 04:38 »
I just also wanted to throw this in as well for future ports:
http://allegrogl.sourceforge.net/
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

Snarky

  • Global Moderator
  • Private Insultant
    • I can help with proof reading
    • I can help with translating
Re: Initial AGS Engine Source Code release
« Reply #170 on: 24 Jan 2012, 16:20 »
About source code licensing:

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

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

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

...

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

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

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

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

Re: Initial AGS Engine Source Code release
« Reply #171 on: 28 Jan 2012, 12:49 »
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: sev
As of the AGS development, anyone is welcome to come with an engine ported to our framework and according to our standards. Current AGS source code is a mess and has to be refactored heavily. This will lead to two incompatible codebases and if AGS community will continue developing original AGS engine, it will turn into an endless race for the compatibility.

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

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

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

What's wrong with that?

Eugene


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

...

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

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

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

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

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

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

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

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

I would like to be more positive with the future of AGS, but with lack of a proactive attitude to collaborating and lack of developers... I don't see things in a positive way until that changes.
« Last Edit: 28 Jan 2012, 13:26 by timofonic »

monkey0506

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
Re: Initial AGS Engine Source Code release
« Reply #172 on: 28 Jan 2012, 22:06 »
Tim. You keep coming here, telling us how we need to be exactly like ScummVM or else there is no way that AGS can be a successful program. The AGS engine source code could have been refactored by anybody, but no one has had the time or motivation to do it. If someone did, then we could move on with one, consistent codebase. Everyone (especially you) keeps making this assumption that we're going to refactor the code and then for some reason continue development of the existing codebase as a separate fork. That's blatantly ignorant.

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

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

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

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

RickJ

  • fix'n one thing and break'n two ...
    • I can help with scripting
    • I can help with story design
    • RickJ worked on a game that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #173 on: 29 Jan 2012, 00:31 »
I don't think Tim is trolling ; There is just a culture clash between the two groups.  Here is a thread on their forums where I've made a couple of positive suggestions to find ways of working together and the responses are typically negative such as this...

Quote
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...

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


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

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

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

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

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

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

I have a slightly different point of view on this.

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


Eugene
few engines)

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

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

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

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

In short: The AGS community needs to evolve first to make AGS evolve too. ScummVM community is technically and organizatively quite superior to the AGS one. AGS community is very superior in artistic stuff (game design and such) than ScummVM community for very obvious reasons.
« Last Edit: 29 Jan 2012, 18:24 by timofonic »

RickJ

  • fix'n one thing and break'n two ...
    • I can help with scripting
    • I can help with story design
    • RickJ worked on a game that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #175 on: 29 Jan 2012, 19:40 »
Quote
So what do you all have to say about this? The ScummVM Team follows AGS too, and some of the most skilled people in the team do it
Tim, the two responses you quote were not responsive to my suggestion, the quote I choose was where the poster "Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream ...
Simple answer: No, won't happen - the scumm devs have other things to attend to..." and nobody disagreed with this assessment.  

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

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

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

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

Quote
Other than that, people still don't get the Copyleft philosophy.
Some do; some don't in both communities.   In the thread I referred to earlier there were a couple of beauties

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

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

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

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

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

That's all I have to say.  I'm sorry that the ScummVM folks have left me with such a negative impression.   I'm sure they are all (or mostly so) nice people in real life but unfortunately they are not fun to talk to on the internet.   :=
« Last Edit: 29 Jan 2012, 19:45 by RickJ »

Snarky

  • Global Moderator
  • Private Insultant
    • I can help with proof reading
    • I can help with translating
Re: Initial AGS Engine Source Code release
« Reply #176 on: 29 Jan 2012, 20:28 »
Tim, no one is against a ScummVM compatible 2.x fork of AGS (at least, I'm not aware that anyone has voiced opposition to it). As you mention, the obstacle to it is that CJ hasn't released the source code yet. Anyway, it would mainly be up to the ScummVM guys; the main interest from the AGS side is in developing the engine further.

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

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

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

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

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

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

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

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

RickJ

  • fix'n one thing and break'n two ...
    • I can help with scripting
    • I can help with story design
    • RickJ worked on a game that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #177 on: 30 Jan 2012, 07:37 »
Quote
Rick, I agree with most of what you write, but are you certain about these two points? My understanding of the GPL is that you can at least argue that if you create and distribute a binary that contains GPL code, everything else that goes into the binary must also be released under the GPL, including any data.
I believe what the GPL refers to is data required in order for the program to function properly.  They are trying to protect against someone crippling an open source program by requiring people to purchase a key for example.   I'm not 100% certain nor am I an attorney.  Who knows what kind of hay could be made of this in some court in some country?  

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

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

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

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

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

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

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

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

Quote
Secondly, I thought the GPL notion of "distributing source" accepted "providing a URL to somewhere the source can be downloaded from" as valid. Or am I missing your point?
Your are correct about the offer to distribute.  The problem is that you have to know what version of source that was actually used to make the binary you are distributing.  You would then have to extract that version of the source from scummvm repository and post it on your website.  You would also have to get copies of the correct versions of any libraries and their source used to by that version of the binary.  You would have to do this for each platform you distribute your game for.   Now if you make another game you will have to do this all over again.  This is an insurmountable task for many AGS users.

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

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

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

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

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

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


« Last Edit: 30 Jan 2012, 07:56 by RickJ »

Re: Initial AGS Engine Source Code release
« Reply #178 on: 30 Jan 2012, 08:05 »
Quote
So what do you all have to say about this? The ScummVM Team follows AGS too, and some of the most skilled people in the team do it
Tim, the two responses you quote were not responsive to my suggestion, the quote I choose was where the poster "Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream ...
Simple answer: No, won't happen - the scumm devs have other things to attend to..." and nobody disagreed with this assessment.  

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

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

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



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

It can be a nice idea for "AGS 4" :)

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

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

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

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

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

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

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

Quote
Other than that, people still don't get the Copyleft philosophy.
Some do; some don't in both communities.   In the thread I referred to earlier there were a couple of beauties

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

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

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

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

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

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

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

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

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

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

« Last Edit: 30 Jan 2012, 08:09 by timofonic »

Re: Initial AGS Engine Source Code release
« Reply #179 on: 30 Jan 2012, 19:54 »
But let's do a little thought experiment to get some clarity.  Suppose there is a GPL media player program that display a PNG file and plays an OGG file.  The programmer was very clever and so the binary and the source don't take up much space so the source, binary, and everything can be easily distributed together.   No I come along with a fabulous photo of myself and an OGG recording of me doing the funniest ever stand-up comedy routine.

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

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

But, as I said, I'm no expert on this.
« Last Edit: 30 Jan 2012, 20:33 by eriktorbjorn »