Topic: Initial AGS Engine Source Code release

[sigbuserror]

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

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

[bero]

[in reply to #40]

Hi,

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

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

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

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

[bero]

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

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

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

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

[Edmundito]

[bero]

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

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

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

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

May or may not work...

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

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

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

[timofonic]

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

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

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

[Snarky]

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

[Calin Leafshade]

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

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

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

[timofonic]

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

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

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

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

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

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

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

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

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

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

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

[Snarky]

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

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

[timofonic]

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

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

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

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

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

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

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

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

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

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

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

[Alan v.Drake]

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


- Alan

[abstauber]

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

[Snarky]

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

[Scavenger]

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

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

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

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

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

[Wyz]

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

Hear hear!

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

[Snarky]

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

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

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

[Calin Leafshade]

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

Not really, no.

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

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

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

[Snarky]

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

[Wyz]

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