Jibble

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

Kweepa

  • Mutated Guano Deviser
    • Best Innovation Award Winner 2009, for his modules and plugins
    • Kweepa worked on one or more games that won an AGS Award!
    •  
    • Kweepa worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #60 on: 07 May 2011, 00:06 »
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

  • 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 #61 on: 07 May 2011, 00:34 »
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

Re: Initial AGS Engine Source Code release
« Reply #62 on: 07 May 2011, 13:44 »
Lot's of chatting, typical of forums. Are there people already working on this? I'm curious about it...

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


- Alan

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

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

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

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

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

Not really, no.

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

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

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

Well, really yes.

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

It's funny to hack your messages :)

Kweepa

  • Mutated Guano Deviser
    • Best Innovation Award Winner 2009, for his modules and plugins
    • Kweepa worked on one or more games that won an AGS Award!
    •  
    • Kweepa worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #63 on: 07 May 2011, 14:14 »
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
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

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #64 on: 07 May 2011, 15:25 »
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.)

Re: Initial AGS Engine Source Code release
« Reply #65 on: 07 May 2011, 16:06 »
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.
« Last Edit: 07 May 2011, 16:08 by JenniBee »

Edmundito

  • Mittens Serf
  • Just tween it.
    • Best Innovation Award Winner 2014, for 'Tween Module'
    • Edmundito worked on one or more games that won an AGS Award!
    •  
    • Edmundito worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #66 on: 07 May 2011, 16:36 »
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.5.0!

Kweepa

  • Mutated Guano Deviser
    • Best Innovation Award Winner 2009, for his modules and plugins
    • Kweepa worked on one or more games that won an AGS Award!
    •  
    • Kweepa worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #67 on: 07 May 2011, 16:55 »
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

  • ...
    • Alan v.Drake worked on one or more games that won an AGS Award!
    •  
    • Alan v.Drake worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #68 on: 07 May 2011, 17:00 »
[...]
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

  • Creator of AGS
  • Administrator
  • Mittens King
  • I sense danger.
    • Lifetime Achievement Award Winner
    • Pumaman worked on one or more games that won an AGS Award!
    •  
    • Pumaman worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #69 on: 08 May 2011, 21:13 »
Quote
The source control provider associated with this solution could not be found. The projects will be treated as not under source control. Do you want to permanently remove the source control bindings from the projects?
Quote
Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

Thanks, I'll fix these in SVN.

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

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

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

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

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

I'll look into this.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Some things, you just can't unsee.
    • I can help with animation
    • I can help with backgrounds
    • I can help with characters
    • I can help with making music
    • I can help with play testing
    • I can help with proof reading
    • I can help with story design
    • I can help with translating
    • I can help with voice acting
    • subspark worked on one or more games that won an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #70 on: 09 May 2011, 00:39 »
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.  ;)

Re: Initial AGS Engine Source Code release
« Reply #71 on: 09 May 2011, 06:20 »
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.


Re: Initial AGS Engine Source Code release
« Reply #72 on: 09 May 2011, 09:19 »
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.

Re: Initial AGS Engine Source Code release
« Reply #73 on: 09 May 2011, 10:05 »
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 :)

Re: Initial AGS Engine Source Code release
« Reply #74 on: 09 May 2011, 11:31 »
Quote
Some files contain very Windows specific code (acwavi.cpp) - while it probably wouldn't be overly hard to replace acwavi.cpp with something using ffmpeg to do the same in a cross-platform way, I know there was a previous Linux port, so some code must already exist - before I start redoing it from scratch, is that code available somewhere?

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

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

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

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

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

  • Mittens Vassal
  • Cavefish
  • Mittens Half Initiate
    • I can help with proof reading
    • I can help with translating
    • I can help with voice acting
    • Monsieur OUXX worked on one or more games that won an AGS Award!
    •  
    • Monsieur OUXX worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #75 on: 09 May 2011, 16:14 »
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.
 

Re: Initial AGS Engine Source Code release
« Reply #76 on: 10 May 2011, 09:16 »
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 :)

Re: Initial AGS Engine Source Code release
« Reply #77 on: 10 May 2011, 22:12 »
Quote
There's a copy of the Allegro headers in the source (Common/libinclude/allegro) -- some of those files should be autogenerated by the Allegro build process instead of being included (e.g. alplatf.h says #define ALLEGRO_MSVC). I can see a couple of possible fixes there:

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Initial AGS Engine Source Code release
« Reply #78 on: 10 May 2011, 22:45 »
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: [Select]
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: [Select]
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.

Bero, are you familiar with git and gitorious?

Yes, I'm a Qt guy...

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

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

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

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

Edmundito

  • Mittens Serf
  • Just tween it.
    • Best Innovation Award Winner 2014, for 'Tween Module'
    • Edmundito worked on one or more games that won an AGS Award!
    •  
    • Edmundito worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #79 on: 11 May 2011, 05:57 »
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: [Select]
  "_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: [Select]
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.5.0!