Messages

I just have one Debian installation and use chroots for building. One can easily build the Debian package using pbuilder or cowbuilder. I think it's also no big deal to set up Debian chroots on Ubuntu and use them for building.

Here you go: http://people.debian.org/~thansen/ags+libraries_20130206.tar.xz

We have no plans for a PSP release, so it shouldn't be an issue.

we could encourage game developers to add perfomance options to their games, like switching extra effects on/off.
These options could be hidden, and activated only from script as a reaction to platform check, like either game runs on "hi-end" or "lo-end" platform.

Please don't use the platform check for that. Remember what the result was for Gemini Rue. For example, there are slow and quite fast Android devices.

I pushed a change enabling StdScale up to 8x. Seems to work just fine. Don't know about performance, my PC handles it.

I thought the autoscale feature did make it in the release that we used?

It is in my upload from February 4, but you used the older one (at least concerning ags64).

For the current development version 3.3 would be suitable I think.

Normally version numbers should exactly define what the code is. So one commit could be tagged with the version and that's the version. For development versions that does not work. We could use odd minor versions for development versions and even versions for releases, so that we would have version 3.3 now and some time in the future there will be tagged commits 3.4, 3.4.1, 3.6, 3.8 etc.

Is there maybe still a check for the platform to be Windows in place somewhere?

I want to write a small configuration generator script for the releases. Is there a way to get the current display resolution from ags/allegro? Would it be possible to add a --display_geometry or something that would spit out: color depth, resolution, etc? Then my script could parse that and "suggest" intelligent defaults for the config?

For the Gemini Rue beta, a LOT of people complained about the game launching in fullscreen and only seeing a tiny postage stamp sized window in the middle.

Yes, because you used my binary from January 30. *facepalm*

Do we need any of the sound settings on Linux?

No idea, I guess most Linux players kept them so far and they didn't do any harm.

Ultimately the simple solution would be a BUILD_STR. Did that get rejected? I didn't get any feedback, or maybe I just don't understand how github works.

You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)

The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.

Should we change this before we release?

I guess you could start the beta test without it.

Here is the thread about the Mac OS X port: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.0

In a nutshell: either AGS has to be ported to Allegro 5 or Allegro 4.4 has to be ported to Mac OS X 10.7.

Maybe AGS uses external code incorrectly. Does not shut it down properly or so. But the bug could still also be in AGS.

Sounds like something I once experienced with a different engine. There was a bug in a sound library that was used, and the sound got corrupted sometimes. Even after quitting the game engine and restarting, the sound was still corrupted. Rebooting would help. That sound library is not used in AGS though.

So the file is not needed on Linux right?

Anyone care to take this package out for a test drive and give me any feedback before I send it off to Wadjet.

Here, autoscaling is disabled, because gfxfilter=StdScale2 is set in acsetup.conf. Also, is ags_shell.dll a Windows plugin?

Here is the new build: http://people.debian.org/~thansen/ags+libraries_20130204.tar.xz

I added automatic selection of the appropriate StdScale filter for the case that no filter is set, but did nothing to make sure that the screen resoltion is not changed.

EDIT: By the way, missing menu sound and rain in Gemini Rue are expected, because they were disabled by the creators unless you use Windows.

I'll have a look at the scaling first and then upload another build (today). It is ok if I make autoscaling the default as suggested in the last post?

I would say that this would be the best for Windows too. The engine knows the game resolution and it queries the desktop resolution so it would be possible to calculate the appropriate scaler automatically. Sinced scaled graphics are more costly on the CPU we should make this optional, maybe with a new scaler parameter like "StdScaleAuto".

If it is better, I think it should be the default and the option should be to turn it off. Something like allow_screen_resolution_change? One could use filters (including "None") to disable auto scaling. In windowed mode, the window could be scaled to something like the screen resolution minus 50(?) pixels in height per default.

BigMc: can you do a build of your ags+libraries with the big merge that just happened? Can you give is a BUILD_STR=$(date +%F)? I'll use that binary as a basis for my Gemini Rue beta.

BUILD_STR is not merged.

Yes, scottchiefbaker. 

No, if we can provide an engine compatible with Windows savegames, we should do it.