Initial AGS Engine Source Code release

Started by Pumaman, Wed 27/04/2011 01:55:57

Previous topic - Next topic

Kweepa

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

Joseph DiPerla

Isn't there a wrapper for SDL for those who use Allegro? I could be wrong and it might not be of much help, but maybe a wrapper would be helpful.
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

timofonic

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

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


- Alan

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

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

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

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

Quote from: Calin Leafshade on Fri 06/05/2011 14:08:49
Quote from: Snarky on Fri 06/05/2011 13:55:12
if we want to make our adventure game engine multiplatform, and ScummVM has a backend to run adventure game engines on many platforms, there might be some synergy there, no?

Not really, no.

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

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

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

Well, really yes.

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

It's funny to hack your messages :)

Kweepa

Quote from: timofonic on Sat 07/05/2011 13:44:25
Lot's of chatting, typical of forums. Are there people already working on this? I'm curious about it...
Well, are you?
There's such a thing as deciding on a course of action.

Quote
Quote from: Alan v.Drake on Fri 06/05/2011 09:01:16
ScummVM is meant to play old junk
It's funny that you say this
I think that's why he said it.
However, the rest of his point (that you punted to a mythical ScummVM dev) is good.

As I said above, it makes more sense to skip the middleman (ScummVM) and go straight to SDL.
Still waiting for Purity of the Surf II

Snarky

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

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

JenniBee

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

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

edmundito

Snarky's got the priorities right. :D

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

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

Kweepa

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

Alan v.Drake

Quote from: timofonic on Sat 07/05/2011 13:44:25
[...]
I consider very humilliating your way of thinking to ScummVM, undervaluing classic videogames that are still considered as the best games of the adventure genre. They aren't "old junk" at all, but software to be preservated and able to use it in modern platforms.
[...]

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

You made me post off-topic, happy now ? :(


- Alan

Pumaman

QuoteThe 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?
QuoteProject : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

Thanks, I'll fix these in SVN.

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

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

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

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

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

I'll look into this.

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.

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.

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

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

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.

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

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

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!


subspark

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

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

Again, welcome.  ;)

sigbuserror

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


JawCross

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

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

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

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

timofonic

Quote from: subspark on Mon 09/05/2011 00:39:31
Welcome to the forums, JenniBee and timofonic. Glad to see new blood here in the AGS circle.
I encourage you to skim through the various areas of our forum so that you can form a cognitive map of the general orientation/history/tastes/humor of our community.

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

Again, welcome.  ;)


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

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

Electroshokker

Quote from: Pumaman on Sun 08/05/2011 21:13:01
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.

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

Quote from: Pumaman on Sun 08/05/2011 21:13:01
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!

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

Monsieur OUXX

Quote from: Kweepa on Sat 07/05/2011 16:55:10
Ooops, I didn't realise SDL doesn't yet support iPhone or Android.

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

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

Just mentionning it, to save some time.
 

timofonic

Quote from: Ouxxey_games on Mon 09/05/2011 16:14:51
Quote from: Kweepa on Sat 07/05/2011 16:55:10
Ooops, I didn't realise SDL doesn't yet support iPhone or Android.

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

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

Just mentionning it, to save some time.

In fact the engine is built on top of OSystem.

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

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

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

I just wanted to clarify it a bit more :)

bero

Quote from: Pumaman on Sun 08/05/2011 21:13:01
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.

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

Quote from: Pumaman on Sun 08/05/2011 21:13:01
For Linux/other platforms, maybe the advice should be to delete the Allegro folder from Common/libinclude, which should allow it to fall-back on the system allegro installation.

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

Quote from: Pumaman on Sun 08/05/2011 21:13:01
As far as I remember, video playback was never implemented in the Linux port. Indeed, the acpllnx.cpp just stubs out the PlayVideo function.

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

Quote from: Pumaman on Sun 08/05/2011 21:13:01
I may well provide the source to legacy versions at a later date.

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

Quote from: Pumaman on Sun 08/05/2011 21:13:01
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.

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

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

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

bero

Quote from: JawCross on Mon 09/05/2011 09:19:33
Hi I'm interested in to get AGS compiled and working under (64-bit) Ubuntu.

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

For libalfont, run (inside the alfont directory)

Code: ags

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


For libcda, run (inside the libcda directory)

Code: ags

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/


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

Quote from: JawCross on Mon 09/05/2011 09:19:33
Bero, are you familiar with git and gitorious?

Yes, I'm a Qt guy...

Quote from: JawCross on Mon 09/05/2011 09:19:33
Your patches are good, but it would be difficult to handle and use them when they scatter around forum. I haven't yet see any plans for merging them to the svn, so maybe they should be collected one place just now.

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

Quote from: JawCross on Mon 09/05/2011 09:19:33
File libcda/libcda-0.5/COPYING contains zlib-license, but also some fuzzy license which covers files: djgpp.c, bcd.doc.

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

edmundito

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

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

Code: ags

  "_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 , 


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

Code: ags

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)


Known mac issue with freetype. Have not found an answer to this one yet. I'm using Electroshokker's alfont source.
The Tween Module now supports AGS 3.6.0!

SMF spam blocked by CleanTalk