Messages

Out of interest, why isn't it safe for AGS to assume that every string ought to be translated before running an operation like this?

Not all strings are used for display purposes, and so if AGS tried to translate every string usage in the script, it would end up translating things that shouldn't be translated, and you'd end up with unpredictable results if you were trying to use strings to build up lists or for other things.

Interesting, has anyone else had a problem like this?

Yes, you need to use GetTranslation for that. It's not possible for AGS to determine automatically whether it should translate text in that sort of scenario.

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?

Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

Thanks, I'll fix these in SVN.

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.

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...

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.

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.

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.

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.

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.

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.

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.

- 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!

Realistically, weeks. I need to sort out some hardcoded paths and check the licensing around the MSSCCI code, amongst other things.

Also, the AGS.Native assembly requires the full Visual Studio to compile it, the free VC++ Express edition will not work. So this means that anyone who wants to work on changes to it will need to own a copy of Visual Studio 2008.

As I said, I don't think this is addressing the root cause of the problem... what we should be doing is fixing the problem that causes the audio file timestamps to keep changing.

Game.agf contains timestamps of audio files which seem to get updated a lot. Sharing this between different people leads to lots of needless editing conflicts.

I think this timestamp thing is actually a bug in the editor, it seems to be doing something funny with the Summer Time +1 adjustment every time you load/save the game. It needs to be looked into.
If the actual audio files haven't changed, the timestamps shouldn't change either.

It seems CRM files contain a compiled version of the ASC source. If one user modifies the background image and another user only modifies the script, both will get a modified CRM file that's impossible to merge because of its binary format. There's a workaround for this - if you only modify the script, you don't really need to check in the modified CRM - but it's still quite inconvenient.

Yes, when you change the script, it is compiled and the bytecode is written to the CRM. The problem here is that the CRM functions as both a "source" file (in terms of room backgrounds, objects, etc) and a "compiled" file (in terms of the script). It would be nice to separate this out at some stage.

The sprite file can easily grow huge and it's unmergeable.

This can be an issue, yes. At the moment the editor and engine use the same format for the sprite file, so the benefit here is that if you have a lot of sprites, AGS doesn't have to do any work to build/run the game (since the engine can just access the sprite file that is already there).

Sounds good ... did you book the hostel in the end?

The way the outline currently works, it renders the text in black 8 times at 1-pixel offsets around the actual text location, then renders it on top once in the correct colour.

However I think the outline rendering is being anti-aliased too, it could be that disabling the anti-aliasing of the black text would provide a better look.

Thanks for all your positive feedback about this decision!

Chris, 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?

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.

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

As this is quite a specialized hardware setup, it's going to be difficult for us to debug this since we'd need to have the hardware too in order to see the problem.

Is it now working to a satisfactory standard?

I am somewhat confused with this music.  In the last version of AGS, the music was defined with each room.  Now that seems to be a problem because it is starting over when changing from room to room.  So, I removed the "playmusic" from all the rooms but the first and set the properties in the audio folder, but it seems this does not always work in other rooms.  So since I have imported a game, what is the correct way to do this?  Each room should have the playmusic or only the first?

Ah well spotted, yes this seems to be an error in the upgrade process, where the editor just adds a music.Play() to the room load -- it should in fact check if music is already playing before doing this.

Here is a sample of the text in the gui, which displays okay with the outline. The second sample, look at the text to the right and the third sample, text to the left.  You'll see, especially with the o's, that certain parts look like they are disappearing.

Ah, I think this is because AGS 3.2.1 now supports anti-aliasing TTF fonts on transparent GUIs, which it didn't before. However this particular font doesn't seem to be anti-aliasing very well (someone else had a similar problem), so we probably need to look into improving this.

Is the compiler included in this release?

I assume thats included in the ags.native assembly but i dont see the code for it.

No, the editor's Native assembly is not yet released. That will follow, but has further complications and it also cannot be compiled by the free Express versions of Visual Studio, which makes a source code release less useful.
Obviously though, to make any changes that need the game compiler to produce a different output, this will need to be modified so I will be providing the source in due course.

I'm having some problems compiling the engine in VC++ 2008. First off there is a reference to dinput.h which is not included. This can be fixed by installing the Direct X SDK and adding the SDK's /include/ folder to the VC++ include directories (just like /Common/ and /Common/libinclude/).

Ah thanks, I should have mentioned this. First post updated.

Then in almp3.c there are hard coded #include paths to mpg123.h and mpglib.h.
I tried changing these to just "mpg123.h" and "mpglib.h" so that they include files from the libinclude folder. This doesn't seem to be the right files though, because it generates a bunch of compile time errors:

Well spotted, I've checked in a fix for this so please try again with the latest version.

Basically the complication here is that AGS uses both ALMP3 (for MP3 playing) and APEG (for Theora video), but ALMP3 and APEG each use different versions of another library called MPGLIB. So AGS ends up having to include two different MPGLIBs, and has to manually direct ALMP3 to one of them and APEG to the other.

Thanks!

As for the scaling ... in previous versions, when in Walkable Areas mode it used to display the %scale at the mouse cursor, as well as the mouse co-ordinates. Thinking about it though, this might have been 2.72 that did this, maybe it was never re-implemented in AGS 3.x?

Allegro 4 is perfectly capable of higher resolutions, and AGS already has its own Direct3D driver to provide hardware acceleration.

So I think we'd need to take a close look to see if moving to Allegro 5 would actually provide any benefit.

Very initial thought: the headers on some of the files need to be altered to reflect the change of licensing.

Good point, I need to update those.

First stop: finding out how portable it is, I first might try to compile it with other compilers and see how much breaks. I know the plug-ins will break, but that will be the first step toward cross-platform compatibility.

The codebase includes all the changes that were made to get the Mac and Linux ports working, so getting these to build should not be a big task.

The platform-specific code is in the ACPLXXX.CPP files, where ACPLWIN is the Windows port, ACPLLNX is the linux one and ACPLMAC is the mac port. However these may no longer build correctly with the latest 3.2.1 code, so may need some fixing up.

Why not have a development branch and branch the stable versions from that one, instead of the other way round?

1) we might want multiple development branches at the same time (eg. a 3.2.2 branch with minor fixes, and a 3.3 branch with major changes)
2) I have complete control over what goes into the trunk
3) it is standard practice with SVN

The RGB colour selector only works up to Index 31. The rest of my palette slots are represented by the 16bit colour space (blue, in this case)

I've fixed this in the 3.2.2 dev branch in SVN.

Hm.  I actually just got a new mouse and now the "get coordinates" function barely works at all.  It works maybe 1 click in every 5.  It wouldn't be a problem if I could still use the right mouse button, but that functionality seems to have been taken out entirely.  Is it possible to put that back in?  Or at least provide an option to switch between them?

Sounds like a good idea -- at least for the filter modes that don't use the right button as an eraser.

When moving an object after zooming in and out, the floating co-ordinates no longer appear next to the object.

Recent versions of the editor no longer seem to display the scale of a walkable area at the mouse pointer. This makes it very difficult to create smooth transitions from one walkable area to another.

Can a developer take a look at these please?

am importing my game from 3.1.2 into this latest version.  I've noticed two things so far.  My music for the rooms doesn't carry into the next rooms but starts over with every new room and my text outline is displaying improperly.  For the music, do I need to change the properties of each music file from Inherit to DefaultRepeat? Any suggestions about the font outlining?

What's the problem with your text outline?
Has anyone else had these problems with the room music?

[DO NOT]

Now that 3.2.1 has been released, AGS seems to be in a stable enough state to release the source code.

So, to that end I've added it to the SVN repository here:
https://svn.adventuregamestudio.co.uk:7743/svn/ags/trunk
you will need the Common, NativeLibs and Engine folders within this.

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 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 the VC++ Options, you'll need to add the /Common and /Common/libinclude folders to the VC++ Include Directories list.

You will also need to install the DirectX SDK from Microsoft if you don't already have it.

DO NOT use this source code as a learning resource or a guide on best practice.
The state of the source code is VERY BAD and should in fact be considered an example of BAD PRACTICE.
Unlike the AGS Editor code which is relatively modern and a generally good standard, the engine code dates back 12 years to 1999, and has a severe case of the another-bit-being-bolted-onto-the-side disease. It also retains compatibility with old versions which means that some of the old and particularly dire code paths cannot yet be removed.
So just to be clear, YES I KNOW that the code is in a bad state. You don't need to tell me that.
I also know that AGS is used by thousands of games with thousands of combinations of game settings and script functions, and that any attempt to refactor the code into a better state is likely to inadvertently break something in someone's game, which is why I haven't attempted to do it yet.

The first important question is, does it compile for you? I'm not 100% sure that I've uploaded everything it needs into SVN, so let me know.

If you're thinking about making a change to the engine, make sure you always consider:
* How does the change affect existing games? Will it break any backwards compatibility?
* Does the change work with all colour modes (8-bit, 16-bit, 32-bit)?
* Does it work with both "low-res" (320x200/320x240) and "hi-res" (640x400 upwards) co-ordinate systems?
* Does it work with both the DirectDraw and Direct3D graphics drivers?
* Is it cross-platform (ie. is there anything platform-specific that would break the Mac and Linux ports?)

If you're thinking about adding third-party libraries, remember that AGS must not use GPL libraries as the GPL license is too strict. Libraries licensed under the Lesser GPL (LGPL) are ok, however.
Always carefully read the license of any third-party libraries before proposing to use them in AGS.

Ok, I have now formally released 3.2.1 to the website, built a plain ZIP version and non-MP3 version.

Developers, I've merged the 3.2.1 branch into the trunk and closed it.
There is now a new dev/3.2.2 branch so please use that to continue with any new fixes!

I did however run into a problem. I went to check out the new Show Characters feature on the room editor.
When i clicked on a character in the room i got and error.
I sent an error report.

Is this crash still happening for you? If so, can you send another error report please (I think I might have accidentally deleted your original one).

The orientation thingie is cool, but when I make the slightest of clicks on a control and having forgot to use LOCK on it, it moves. That's terribly annoying, can we somehow enable and disable new stuff. Same goes for that +. That's annoying as well.

Is this any different from previous versions of AGS that didn't have the Lock function?

I have a bug. The RGB colour selector only works up to Index 31.

Well spotted, thanks. I'll fix this.

Speaking of the GUI, I noticed it is no longer possible to click on the background to select the GUI in the properties editor, instead you have to select it in the dropdown list of the properties editor. (this worked in 3.1.2 SP1)

This seems fine for me, does anyone else have this problem?

I've been having occasional trouble triggering the autocomplete. Sometimes it just stop working from one moment to the next. I then have to build/run the game to reactivate it. Doesn't matter if it compiles without errors or not, just the act of running it somehow kicks up the autocomplete again.

As this is an existing issue that affects previous versions, we can look at it later.

This was a simple fix to make, so I checked in a fix to the dev branch.

Could you guys please not check anything else into the 3.2.1 dev branch.
I don't think any of the bugs reported here are serious enough to justify doing another 3.2.1 build and holding back the release, so I'll make the current version official and create a 3.2.2 dev branch to carry on with further changes.