Initial AGS Engine Source Code release

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

Previous topic - Next topic

kingstone

Quote from: Pumaman on Thu 28/04/2011 14:43:55
Well spotted, I've checked in a fix for this so please try again with the latest version.
Good job, that solved it!

There's one more problem with the current revision, version.rc fails to #include "afxres.h". A few minutes of googling hinted that this is because afxres.h is an MFC include which does not come with VC++ 2008 Express.

I fixed the problem by exchanging:
Code: ags
#include "afxres.h"

for:
Code: ags
#define IDC_STATIC -1
#include <windows.h>


That's it, I now have a freshly compile acwin.exe that works perfectly! ;D Thanks again!

Joseph DiPerla

Wow amazing! When I get back from Oregon, I will take a look at the code. This is awesome. I am learning c++ and c# currently and hopefully sometime in the future I can help with this project. Thanks CJ!
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

perludus

Alright! 

So if this could turn into an up to date Mac version, or better yet an embedded (via Flash?) web player for games, I would be in 7th heaven.

Dave Gilbert

Yay!

AGS has taken it's first eager steps into the wild. 

This is *extremely* exciting news, CJ.  Thanks for doing this.  I'm looking forward to seeing what happens next.

Pumaman

Thanks for all your positive feedback about this decision!

QuoteChris, are any parts of the source still closed?

I could release my linux Code::Blocks projects (with instructions) with your permission. (Can I release older versions of the engine or only the latest?)
I'm sure some of the more enthousiastic folks out there would love to start from a proper IDE setup, rather than starting with raw code.

The only part of the source that is not yet released is the editor's Native DLL. Everything else is now in SVN.

Yes, please do release that -- would be really useful for other people trying to build in Linux. Could you upload it in a ZIP since I'm the only one that has permissions to check in to the trunk?

QuoteThere's one more problem with the current revision, version.rc fails to #include "afxres.h". A few minutes of googling hinted that this is because afxres.h is an MFC include which does not come with VC++ 2008 Express.

Interesting, thanks. I'll check that fix into SVN.

Sslaxx

I'd suggest using something like CMake with the engine code could be useful. That'd handle dependencies and create project files for Visual Studio, standard Makefiles, Code::Blocks etc. It's in use with a few projects, such as Allegro, OGRE and OpenMW for three.
Stuart "Sslaxx" Moore.

sigbuserror

Hi everyone! I got the code to compile to an exe, but now I am not sure how to test it with data. Is there a way to use the demo game resources without building the whole editor etc?

Sslaxx

If you can find a game compiled with AGS 3.2.1, you can run it using the compiled exe.
Stuart "Sslaxx" Moore.

Calin Leafshade

ya, either run the compiled exe as an argument like:

acwin thegame.exe

or replace the acwin in your AGS editor folder and compile a new game.

sigbuserror

cool that works! strange that the editor doesn't spit out a data bundle at some point before merging with an exe. ;D

edmundito

Woohoo! This is awesome! I was able to compile my own version of ACWIN! I think there's a tear coming out of my eye...

I ran into into warnings and 1 error (in the release build) along the way that are easy to fix but I think they should be mentioned so we can start cleaning things up. Should I post about these things, though? Should we start a separate thread about building the engine source code?
The Tween Module now supports AGS 3.6.0!

Sslaxx

Quote from: Edmundito on Sat 30/04/2011 19:30:20
Woohoo! This is awesome! I was able to compile my own version of ACWIN! I think there's a tear coming out of my eye...

I ran into into warnings and 1 error (in the release build) along the way that are easy to fix but I think they should be mentioned so we can start cleaning things up. Should I post about these things, though? Should we start a separate thread about building the engine source code?
Post here for now, I'd say.
Stuart "Sslaxx" Moore.

edmundito

#32
Just a few notes about what I've run into so far. I was able to make the three builds, there were just a few things that happened on the way there that should be mentioned:


As soon as you open the project in VSC++ Express you get a warning about the source control binding (the scc plugin is not part of the standard edition):
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?



I got these warnings in the Debug and Release builds:
Quote
Warning   1   warning C4018: '<' : signed/unsigned mismatch   wwnd.c   473
Warning   2   warning C4244: '=' : conversion from 'sample_t' to 'float', possible loss of data   itrender.c   484
Warning   3   warning C4244: '=' : conversion from 'sample_t' to 'float', possible loss of data   itrender.c   485
Warning   4   warning C4244: 'function' : conversion from 'float' to 'int', possible loss of data   itrender.c   2971
Warning   5   warning C4244: 'function' : conversion from 'float' to 'int', possible loss of data   trender.c   2974
Warning   6   warning C4244: '=' : conversion from 'long' to 'byte', possible loss of data   itread.c   244
Warning   7   warning C4244: '=' : conversion from 'long' to 'byte', possible loss of data   itread.c   253
Warning   8   warning C4005: 'int64_t' : macro redefinition   ogg.c   6
Warning   9   warning C4005: 'DISABLE_MPEG_AUDIO' : macro redefinition     mpg123.c   8
Warning   10   warning C4005: 'DISABLE_MPEG_AUDIO' : macro redefinition     mpeg1dec.c   1

Only in the Debug build:
Quote
Warning   11   warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library   acwin

In the NOMP3 Release Build I got 427 warnings :S. Mostly on POSIX stuff. Example:
Quote
Warning   17   warning C4996: 'write': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _write. See online help for details.   file.c   2975



I did get this build error when building the Release and NOMP3 Release version:
Quote
Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

It turns out that the post-build events settings in the project you got some copy commands specific to CJ's computer:
Quote
cmd /c copy e:\code\ags\acwin\release\acwin.exe e:\code\ags\agsedit\release
cmd /c copy e:\code\ags\acwin\release\acwin.exe E:\Code\ags\netedit\AGS.Editor\bin\Debug



Finally, what I did to add the common dirs to the project instead of adding it to the Visual Studio settings:
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
4. These additions could be potentially checked in that way people don't have to do it manually. ;)
The Tween Module now supports AGS 3.6.0!

Kweepa

#33
Quote from: Edmundito on Sat 30/04/2011 21:36:12
I got these warnings in the Debug and Release builds:
It's not a good idea to fix these warnings as they are in library code. Any fixes will confuse diffs and get lost when the libraries are updated.

Quote
Only in the Debug build:
Quote
Warning   11   warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library   acwin
This can easily be removed by going to the project properties, Linker/Input/IgnoreSpecificLibrary and adding ,LIBCMT to the end.

Similarly, the /LTCG warning can be removed by going to Linker/Optimization/LinkTimeCodeGeneration and changing the property to Use Link Time Code Generation.

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:
save game
scripting (still quite big)
events
mp3
allegro
recording and playback
editor communication (debugger)
sound
packfile
translation
blitting
resolution support
dirty rectangles
tinting, lighting
draw
room
cursor
region
quit?
drawingsurface
dialog
datetime
viewframe
string
dynamicsprite
overlay
gamefile (load/unload)
gameoptions
display
speech
raw* functions
object
character
maths
fli
theora
inventory
gui (perhaps by control: textbox listbox button etc)
hotspot
game_get* functions
system_* functions
parser
file
mouse
viewport
interaction
script exports
mainloop
config
main

That would make most of these files 300-1000 lines each, which is good for comprehension and collaboration. We'd want to push most of these into sub folder(s).

Unfortunately it's pretty much a one-man job.
Still waiting for Purity of the Surf II

bero

#34
Hi,
Thanks for releasing the source! I'm trying to get it to build on Linux - and I've been mostly successful, it compiles and links fine now using CMake (http://cmake.org/).
I've tried to keep everything portable, so with any luck, you can also use this on any other platform. (But I've only tested it on Linux; others may or may not work).

A couple of problems before I start sending patches:

  • 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
    cd Common
    svn mv Wgt2allg.h wgt2allg.h
    svn mv CSCOMP.H cscomp.h
    svn mv CSRUN.CPP csrun.cpp
    svn mv FMEM.H fmem.h
    svn mv FMEM.CPP fmem.cpp
    svn mv MOUSEW32.CPP mousew32.cpp
    svn mv libinclude/AASTR.H libinclude/aastr.h
    svn mv libinclude/AAUTIL.H libinclude/aautil.h
    svn mv libinclude/ALFONT.H libinclude/alfont.h
    svn mv libinclude/ALFONTdll.H libinclude/alfontdll.h
    svn mv libinclude/AASTR.H libinclude/aastr.h
    svn mv libinclude/ALOGG.H libinclude/alogg.h
    svn mv libinclude/ALOGGDLL.H libinclude/aloggdll.h
    svn mv libinclude/ALMP3.H libinclude/almp3.h
    svn mv libinclude/LIBCDA.H libinclude/libcda.h
    svn mv libinclude/ALDUMB.H libinclude/aldumb.h
    svn mv libinclude/DUMB.H libinclude/dumb.h
    svn mv libinclude/INTERNAL libinclude/internal
    svn mv libinclude/internal/ALDUMB.H libinclude/internal/aldumb.h
    cd ../../Engine
    svn mv AC.CPP ac.cpp
    svn mv ALOGG.C alogg.c
    svn mv libsrc/aastr-0.1.1/AASTR.H libsrc/aastr-0.1.1/aastr.h
    svn mv libsrc/aastr-0.1.1/AASTR.C libsrc/aastr-0.1.1/aastr.c
    svn mv libsrc/aastr-0.1.1/AAUTIL.H libsrc/aastr-0.1.1/aautil.h
    svn mv libsrc/aastr-0.1.1/AAUTIL.C libsrc/aastr-0.1.1/aautil.c
    svn commit
  • 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:

    • Use system wide allegro installation instead of including allegro
    • Package the allegro sources instead of prebuilt directories
    • Given alplatf.h seems to be the only misbehaved file, drop it and have a correct version generated by the AGS build process
    Not sure which (if any) is preferred by the AGS developers?
  • 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?
  • acwsetup.cpp is very Windows specific - I know there is an old Linux port using gtk 1.x, but given no current Linux system has gtk 1.x installed anymore, I'd propose rewriting it using Qt - that would also be cross-platform.
  • It would be good to document where to find the external dependencies (libraries that aren't part of a standard Linux system, and not included in the source):

I've successfully played King's Quest III Redux with my port.

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?


In case anyone is interested: Here's a patch file with the changes I made: http://arklinux.org/~bero/ags-20110501-linux.patch. Simply apply the patch, then run "sh prepare.sh", "cmake .", "make -j8" and you should have a working ags (in Engine/ags).

If you don't want to apply patches, here's a ready-made source tarball:
http://arklinux.org/~bero/ags-20110501-linux.tar.xz

And for those who just want to play, here's the resulting (Linux 32-bit) binary, built on Ark Linux dockyard-devel, may or may not work with any other Linux: http://arklinux.org/~bero/ags-20110501-linux

Will try to build a native 64bit version next...

bero

With my Linux port, I'm running into a crash in KQ3 Redux when trying to take the Cat's hair.

Looking at the backtrace:

#0  0x08129732 in ?? ()
#1  0x0812a802 in ?? ()
#2  0x0812da30 in do_layer3 ()
#3  0x08130087 in decodeMP3 ()
#4  0x080e8594 in ?? ()
#5  0x080e93bb in almp3_poll_mp3 ()
#6  0x080dfdb4 in MYSTATICMP3::poll() ()
#7  0x080e003d in MYSTATICMP3::play() ()
#8  0x0808a273 in load_sound_from_path(int, int, bool) ()
#9  0x080b202c in PlaySoundEx(int, int) ()
#10 0x080ed701 in call_function(long, int, long*, int) ()
#11 0x080eeb23 in cc_run_code(ccInstance*, long) ()
#12 0x080ef431 in ccCallInstance(ccInstance*, char*, long, ...) ()
#13 0x0808dc2f in run_script_function_if_exist(ccInstance*, char*, int, int, int, int) ()
#14 0x0808de48 in run_text_script(ccInstance*, char*) ()
#15 0x0808d96e in post_script_cleanup() ()
#16 0x0808dd2f in run_script_function_if_exist(ccInstance*, char*, int, int, int, int) ()
#17 0x0808e025 in run_text_script_iparam(ccInstance*, char*, int) ()
#18 0x080922d8 in process_event(EventHappened*) ()
#19 0x08092df3 in processallevents(int, EventHappened*) ()
#20 0x08092e3b in update_events() ()
#21 0x080cd975 in mainloop(bool, IDriverDependantBitmap*, int, int) ()
#22 0x080cddc9 in main_game_loop() ()
#23 0x080d073f in initialize_start_and_play_game(int, char const*) ()
#24 0x080d368c in initialize_engine(int, char**) ()
#25 0x080d1944 in main ()

I guess it's becaue apeg and almp3 both have a (slightly different) copy of mpg123, using the exact same symbol names - probably this is an effect of apeg's layer3 stuff being called from almp3.

I think the best fix (for all platforms) would be to check where the files differ, fix any incompatibilities, and just use 1 copy (and preferrably, replace both copies with the much newer version from http://mpg123.org/ -- among other things, this version fixes major security bugs).

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?

Other than that, my idea would be to introduce some #define hacks to change overlapping symbol names...

bero

Quote from: bero on Sun 01/05/2011 21:18:20
I guess it's becaue apeg and almp3 both have a (slightly different) copy of mpg123, using the exact same symbol names - probably this is an effect of apeg's layer3 stuff being called from almp3.

I've confirmed that this is indeed the problem, (quick)fixed it, and updated my Linux builds.
Patch for this issue at http://arklinux.org/~bero/ags-20110501-apeg-almp3-symbol-ambiguity.patch

bero

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

Here's a list of issues I've found so far:

  • In Common/Clib32.cpp, the MultiFileLib/MultiFileLibNew structures use arrays of "long"s to determine file positions. However, since sizeof(long) == 8 and the longs are read as sizeof(long) bytes from a file created on a 32bit OS (I don't think we want to rebuild the data files to run on a different OS, I like doing "ags Kq3redux.exe" on Linux...), the offsets are read incorrectly.
    Proposed fix: use "int" (always 4 bytes), or even "uint32_t" (guaranteed forever to be 32 bit) instead of long.
    Downside: Limited to 32bit file (4GB) file size even on a 64bit platform -- not a big issue given AGS can split files anyway.
    Without the downside, I think this can't be fixed without a format update that either stores sizeof(long) for the platform the data files were built on, or uses uint64_t everywhere.
  • Various parts of the code pass pointers as parameters to functions requesting an int. Given a pointer is 64bit and an int is 32bit, only half the pointer is passed - this can't work.
    Unfortunately the obvious fix (change "int" to "long" for those) is less obvious to do than it sounds, given the various "int" parameters are passed on to more functions taking int parameters, and longs do cast to int implicitly - easy to miss a use.
    I'm not sure what this is supposed to accomplish in the first place - e.g. the 2nd parameter to do_main_cycle() is an int, but the only valid use seems to be passing a pointer.
    I think the best solution would be having a proper variant type (this is what it seems to be used for -- the ints are typically cast back to short*, char* or int* depending on context), but in the mean time, is there any reason to not just use a void*? At least that shows what's being expected and has the correct size.
  • serialize_new_interaction() tries to putw() and getw() pointers. Should probably just use fwrite/fread...

I have a patch that takes care of those at http://arklinux.org/~bero/ags-64bit.patch.
It compiles now, and goes a lot farther than an initial attempt (before noticing the "long" usage in Clib32.cpp) - but I must still be missing something (probably another attempt to read a "long" from the data files somewhere...):

# /usr/src/repos/ags/Engine/ags Kq3Redux.exe
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 3.21.1115
Speech sample file found and initialized.
Audio vox found and initialized.
Checking sound inits.
jack_client_new: deprecated
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
An internal error has occurred. Please note down the following information.
If the problem persists, post the details on the AGS Technical Forum.
(ACI version 3.21.1115)

Error: No global script in game; data load error


I've compiled a 32bit Linux version with the 64bit patch applied, and that one still works fine, so the patch at large works.


Edit: After looking a bit deeper, I found GameSetupStructBase is read directly from the file, but it has members that are pointers. Obviously on 64bit, those are of a different size - it'll need a workaround like the one that's already there for ALLEGRO_BIG_ENDIAN.
However, I'm not sure how this can work at all (even on 32bit), given we can't just load the value of a pointer from disk and expect it to point to anything useful. I'm probably overlooking some implementation detail.

Electroshokker

#38
Quote from: Pumaman on Sat 30/04/2011 13:43:02
The only part of the source that is not yet released is the editor's Native DLL. Everything else is now in SVN.

Yes, please do release that -- would be really useful for other people trying to build in Linux. Could you upload it in a ZIP since I'm the only one that has permissions to check in to the trunk?


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.

For the rest of you, here's some basic goodies:

Linux AGS Setup Utilities for 2.72 & 3.12 Source Code
Static libraries you can use to build AGS
Sources of the dependency libraries

Quote from: Shawn Walker
The following libraries have to be compiled manually, after which the header files need to be put in the /include folder of the project, and the libraries in the /lib folder of the project.

# alogg library - patch: makefile changed so we get a static library #
description: use Ogg/Vorbis streams with Allegro

# almp3 library - patch: makefile changed so we get a static library #
description: use MP3 streams with Allegro

# alfont library 1.9.2 - patch: src files & makefile changed so we get a static library #
description: use fonts with Allegro

# libcda library 0.5 #
description: cd player functionality

The sources provided are (except for libcda) NOT the original sources found on the web. The makefiles were changed to create static libraries (.a), and for the alfont library the sources where also changed so it supports AGS.

Do not get updated versions of these libraries, unless Chris Jones tells you otherwise.

Next on my list to prep for public release:

- a working code::blocks project for AGS 3.2.1 with updated notes in the project

edmundito

Thanks to the linux info, I decided to dive in and find out how far I could get in building an OS X version. I haven't looked too much into it, but I got as far as building these allegro libraries:

libaldat.a liballeggl.a libloadpng.a liballeg.a libjpgalleg.a liblogg.a

I followed the exact same process with cmake, and I had to make+install my own libogg and libvorbis as well.

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

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. :P
The Tween Module now supports AGS 3.6.0!

SMF spam blocked by CleanTalk