Topic: Initial AGS Engine Source Code release

[kingstone]

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.

Looking forward to it!

[bero]

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.

Looking forward to it!

Done, my port is now imported into http://gitorious.org/ags.

Feel free to do anything you like with it, and add to the wiki.

[RedDwarf]

Done, my port is now imported into http://gitorious.org/ags.

Feel free to do anything you like with it, and add to the wiki.

You have a merge request there. Not really used to git, hope everything is correct.

[bero]

You have a merge request there. Not really used to git, hope everything is correct.

Thanks, looks mostly good to me - I've added a comment on it w/ a couple of remarks and questions.

[Edmundito]

Do you believe in magic?

[subspark]

No. I believe in technology however and you just improved it a great deal!
Well done Edmundito. Well done indeed. 

Sparky. [claps hands]

[Calin Leafshade]

Done, my port is now imported into http://gitorious.org/ags.

Feel free to do anything you like with it, and add to the wiki.

While I think that is awesome doesn't it contravene the license?

Specifically the "You may not distribute this code" part?

Do you believe in magic?

That is also awesome!

...

Does this mean i need to make a mac and linux version of Nimbus? D:

[bero]

While I think that is awesome doesn't it contravene the license?

Specifically the "You may not distribute this code" part?

Quoting the announcement of the source code release (first post on this thread in the forum):

I know there's been a lot of interest in this, so if you're a C++ programmer then the code is now available for your perusal. It's released under the Artistic License 2.0, as with the editor code.

You can read the Artistic License 2.0 here - it clearly says anyone is allowed to distribute modified code under certain conditions we comply with. If there's any "You may not distribute this code" statements left anywhere, I consider them to be obsoleted by that announcement. Correct me if I'm wrong.

Does this mean i need to make a mac and linux version of Nimbus? D:

Of course.

[redspark]

Do you believe in magic?

That's awesome!  I can't wait to start trying it out.

[monkey_05_06]

Now if only I didn't hate Mac OS slightly more than I hate Windows..:

[Dualnames]

It seems that the man that brought awesome to our AGS games with Tweenmodule just did it again. Way to go, Edmundito!!!!!!! 

[RedDwarf]

Looking at the acwin.vcproj I see all the builds, with and without MP3 support, use "DISABLE_MPEG_AUDIO"; which disables MP3 support in apeg without touching almp3. Not sure what are the consequences, since I'm not sure what apeg is used for. But is this expected? No game should suppose ags was build with a copy of apeg with mpg123 support? Since bero is working in being able to have both copies of mpg123 at the same time...

[bero]

Looking at the acwin.vcproj I see all the builds, with and without MP3 support, use "DISABLE_MPEG_AUDIO"; which disables MP3 support in apeg without touching almp3. Not sure what are the consequences, since I'm not sure what apeg is used for. But is this expected? No game should suppose ags was build with a copy of apeg with mpg123 support? Since bero is working in being able to have both copies of mpg123 at the same time...

Educated guess from reading through the code: almp3 is used to play plain sound files (test for almp3: rip out the cat hair in kq3redux, the cat's response is mp3).

apeg seems to play videos that may or may not have an mp3 soundtrack. So yes, both are needed... (And the fix to make both use the same mpg123 is on its way... Good idea anyway, given how many security bugs old mpg123 had)

[helios123]

Like many other people, I have also been busy experimenting with the source for the last couple of days. Here are a few things that I found out:

• I am using Code::Blocks, as the development environment, with the Visual C++ 2008 compiler. Code::Blocks supports importing Visual Studio solution files, so setting up  the project is comparatively easy. We only have to add the lib files in the linker's configuration.
  
• CJ's original post mentions that DirectX SDK is required. But I found that this is not required if you have Windows SDK installed, as it includes the DirectX headers and libs.
  

• You will need Visual C++ Express 2008 (this is a free download from MS). Do NOT use the 2010 version, this will probably not work and let's not complicate things at this stage by trying to use it.

  In spite of this, I tried (out of curiosity, and the fact that support for Visual C++ 2008 Express is likely to be dropped sometime in the near future) to compile the engine using Visual C++ 2010 Compiler (it's bundled in the Windows SDK) using Code::Blocks as the IDE (Note that Code::Blocks does not detect Visual C++ 2010 compiler automatically. We have to manually configure it through Settings -> Compiler and Debugger).
  
  The code compiled (only a single change of typecasting in a call to the abs function had to be made), but the linker complained that it could not resolve a reference to _hypot function in alleg_s_crt.lib. After a little find in files and examining the contents of the allegro 5 dll using objdump (I'm afraid I don't know the MSVC equivalent), I found that the function _hypot is present in msvcrt.dll (which is not being linked, but is probably referred by alleg_s_crt.lib). But it is also in libcmt.lib (which is being linked).
  
  The puzzling thing here (at least to me), is that the same thing works in Visual C++ 2008, while it does not work in Visual C++ 2010.
  Is this the reason why use of Visual C++ 2010 was discouraged, or am I doing something wrong, or is this due to something else?
  

[Electroshokker]

Considering the headway you guys have been making (and my own lack of time and struggle with the almp3 & apeg integrations in 3.2.1), I figure I'd just release the linux video code which you can use as a starting point for proper unix video integration.

Here it is!

the GStreamer api & documentation

GStreamer is a plugin-based framework licensed under the LGPL. (for license mumbo jumbo, read here)

Also, I'd like to note that Allegro 4.4 is fully backwards compatible with 4.2 AND has OpenGL support.

Here's the challenge for you guys:

- working AGS 3.2.1 build on Linux, Mac
- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)
- redesign audio support to use gstreamer, so audio will work properly on all platforms
- create ags plugin support on linux & mac

Have fun with it! If you've got questions, feel free to ask.

[RedDwarf]

- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)

Done... but I don't know how to test it. Any game that is known to require it and work with 3.2? KQ3 has video intro, but it worked before... through apeg/Theora, I suppose.

- redesign audio support to use gstreamer, so audio will work properly on all platforms

Would be nice. But isn't audio working already?

- create ags plugin support on linux & mac

I don't know how the ags plugin system works. But even if added for linux & mac, I suppose already existing plugins wouldn't work since they are compiled for Windows, aren't? They could depend on Windows only libraries... and IIRC the C++ ABI is just different there.

[bero]

- built-in video support using gstreamer framework (for the Mac guys, have a look here and here for the binaries. For gstreamer on windows, look here)

Done...

Great, then I won't touch it until you're ready. No need to duplicate work...

but I don't know how to test it. Any game that is known to require it and work with 3.2? KQ3 has video intro, but it worked before... through apeg/Theora, I suppose.

So far I haven't noticed it missing anywhere either - and I couldn't test my quick-and-dirty one-liner approach (system("mplayer whatever");") either.

- redesign audio support to use gstreamer, so audio will work properly on all platforms

Would be nice. But isn't audio working already?

It is -- it's using almp3/alogg/apeg/libcda, which is a bit of a mess (too many different bits), but it works everywhere. It's a bit less messy now that I've adapted it to use current mpg123 rather than the old internalized copy.
(And I'd argue anything using gstreamer would be a bit of a mess as well, while it works well, I think gstreamer's code is rather awful. But then I'm somewhat biased, I tend to think anything that uses glib is broken by design)

- create ags plugin support on linux & mac

I don't know how the ags plugin system works. But even if added for linux & mac, I suppose already existing plugins wouldn't work since they are compiled for Windows, aren't? They could depend on Windows only libraries... and IIRC the C++ ABI is just different there.

There could be a way to do it by stealing wine's PE loader and most of wine's libraries, but then there wouldn't be much of a point in having AGS natively in the first place because people could just use all of wine. (And of course any attempt to do that on non-x86 Linux (the rest of AGS should work on ARM...) would be doomed to fail.)
It's probably best to just provide an identical API so people can just recompile their plugins to any platform (preferrably releasing the source so people on *BSD, Solaris and whatever can build their own).

[Wyz]

Yes, that would definitely be the best option. I've guaranteed cross-platform support for all plugins I've madeso far in that I will either port it myself or release the source code. If you need plugins to test with: let me know.

[bero]

Yes, that would definitely be the best option. I've guaranteed cross-platform support for all plugins I've madeso far in that I will either port it myself or release the source code. If you need plugins to test with: let me know.

I do - please make a plugin source plus a test game available somewhere, and point me to it.
Thanks!

[Wyz]

I've made a test plugin because I want to be sure the interface is a broad as possible. It is tested (except for saving and loading) but I didn't feel like writing a test game for it. It simply wraps vector<string> and everything gets called from the Array namespace (and has auto-completer hints).

The source:
https://code.google.com/p/ags-plugin-stringarray/source/checkout