AGS 3.3.0 Release Candidate

[Radiant]

I think we should activate, how people call it, "feature freeze policy" for this branch.

I think that's a great idea   Ok, if I'll have any other feature requests I'll defer them to 3.4. It would be great to have a stable 3.3 build with all the new functionality therein.

The only exception may be implementing automatic scaling option in winsetup... although that's not a new feature,

I would argue it's a bug that automatic scaling is not listed in the winsetup drop down   (considering automatic scaling by itself works fine).

[Knox]

I think we should activate, how people call it, "feature freeze policy" for this branch.

Will transparency on text window make the cut?

[Joseph DiPerla]

"Feature freeze policy" is a brilliant idea. Fix the bugs, then for 3.3.1 refactor code some more, 3.3.5 improve portability, 3.4.0 remove limits and add custom resolutions and 3.4.5 new features. Well... that's at least how I would do it. But freezing new features until all bugs are fixed is the best way to go forward.

[Crimson Wizard]

Will transparency on text window make the cut?

It is already there.

[monkey0506]

The Android engine is pretty badly bugged right now, with it silently crashing all the time. If that can be sorted out, then should that be included in the 3.3.0 release?

Yes, this branch is for bug fixes.

BTW, it is important to know if all ports compile and run properly.

I realized this may have conveyed the wrong tone on my part. To clarify, I've had several people report this silent crashing to me, from both the existing launcher APK builds and my stand-alone APK builds. Recent signs point toward the multithreaded audio, but I haven't been able to really pinpoint it (granted, I know nothing about multithreaded programming).

[Radiant]

For what it's worth, the multithreaded audio also causes problems with Windows builds. Perhaps it would be good to disable it for 3.3.0 and reinvestigate it for 3.3.1 or 3.4.

[Crimson Wizard]

The Android engine is pretty badly bugged right now, with it silently crashing all the time. If that can be sorted out, then should that be included in the 3.3.0 release?

Yes, this branch is for bug fixes.

BTW, it is important to know if all ports compile and run properly.

I realized this may have conveyed the wrong tone on my part. To clarify, I've had several people report this silent crashing to me, from both the existing launcher APK builds and my stand-alone APK builds. Recent signs point toward the multithreaded audio, but I haven't been able to really pinpoint it (granted, I know nothing about multithreaded programming).

Not sure I understand what's wrong was about tone conveyance . IMO the ports should at least run games created with latest editor version, so it is equally important to test & fix them all.

Regarding the multithreading, there are different sort of errors: 1) errors due improper use of shared resources (this may lead to crashes); 2) errors due desynchronization or incorrect implementation of the working process (this may lead to sound stutter and similar weirdities); also 3) deadlocks.

Threaded audio is enabled on all mobile ports (Android, iOS, PSP) by default, but can be disabled in config.
On other hand, as far as I undestand this, it may speed things up on these platforms (especially PSP).

By the way, are these bug reports kept someone?

[Crimson Wizard]

Engine with proper support for automatic scaling selection (now should not cause troubles by choosing unsupported fullscreen mode):
http://www.mediafire.com/download/dpb4uve382detl0/acwin.exe
(no, this is not custom resolutions)

Please, test, and tell if that works for you.

How does it work: define filter id as "max" (case insensitive) in config manually

Code: ags

[misc]
gfxfilter=max

or select "Maximal supported" in the filter list in winsetup.

When game is run, engine should choose maximal scaling filter that is supported by your graphic card / renderer mode. In windowed mode the scaling will not make window larger than your current desktop (in fullscreen it actually may).
On other hand, it may happen that windowed mode supports higher scaling than fullscreen.
For example, my display is 1680x1050, it can run 320x200 game on 1600x1000 (x5 filter) in window, but only 1280x800 (x4 filter) fullscreen.

[Radiant]

Thank you, this appears to work fine. We'll test on a few other systems/monitors later this week.

I'm curious if this option gives a nearest neighbor filter or some other kind of filter? And I think it would be better placed near the top (directly below "none") because it's a sensible default and not "the next step beyond 8x scaling". For that matter it may be clearer to split this into two pulldowns: one for the filter (none/NN/AA/H2x) and one for the scaling (max/1/2/3/4...). By the way, you mentioned in another thread that certain options in winsetup don't actually do anything in the engine code, because they're either obsolete or not implemented. I believe it would be a good idea to hide or disable those.

Finally, I'm curious what the status is of the SetMusicVolume fix you mentioned earlier? It's not crucial or anything but I'd just like to know.

[Crimson Wizard]

I'm curious if this option gives a nearest neighbor filter or some other kind of filter? And I think it would be better placed near the top (directly below "none") because it's a sensible default and not "the next step beyond 8x scaling". For that matter it may be clearer to split this into two pulldowns: one for the filter (none/NN/AA/H2x) and one for the scaling (max/1/2/3/4...).

No, I can't split it into two popups right now, because the filters list is created by the engine literally as it is shown there... there's no "filter type" thing, only NNx2, NNx3, etc. Maybe we could get to this later, with the custom resolutions.

By the way, you mentioned in another thread that certain options in winsetup don't actually do anything in the engine code, because they're either obsolete or not implemented. I believe it would be a good idea to hide or disable those.

Not really, I mean that few things that are automatically written to "acsetup.cfg" are not used, at least not by Windows version. Everything what is on winsetup dialog is used.

Finally, I'm curious what the status is of the SetMusicVolume fix you mentioned earlier? It's not crucial or anything but I'd just like to know.

Whoops. I forgot about that. I recall I wasn't very sure what to fix there exactly, I need to look into that again.

[Radiant]

(1) Ok, but I still think this new filter could have a clearer name (e.g. "maximum size nearest-neighbor")
(2) Thanks, that clears things up.
(3) As I recall, you posted a fix in this thread which sounded like a good solution (see next post)

[Radiant]

Here you go:

(edit) As I recall, AGS has these 'room music levels' that nobody ever seems to use much; these probably apply a modifier to the music's overall volume, and the lowest of those might be -60? I mean SetMusicVolume, which has a scale of -3 to +3; it wouldn't surprise me if this maps to -60 to +60 internally. If so, these would need a boundary check to treat totals of less than zero as zero.

Ohhh. Well, in such case this is made not right. I found a code where a room modifier is applied:

Code: ags

int newvol=play.music_master_volume + ((int)thisroom.options[ST_VOLUME]) * 30;
if (newvol>255) newvol=255;
if (newvol<0) newvol=0;

I think this may be fixed by changing this to something like

Code: ags

int newvol = play.music_master_volume + room_modifier[thisroom.options[ST_VOLUME]] * 30;
if (newvol>100) newvol=100;
if (newvol<0) newvol=0;
newvol = newvol * 255 / 100; // convert unit range

Yes, this will require to keep master_volume in 0 - 100 range throughout the code.

[Alan v.Drake]

On other hand, it may happen that windowed mode supports higher scaling than fullscreen.
For example, my display is 1680x1050, it can run 320x200 game on 1600x1000 (x5 filter) in window, but only 1280x800 (x4 filter) fullscreen.

Because you have to manually add that resolution to your drivers, I too have a 1680x1050 panel and my monitor sends an EDID to the drivers that lacks other obvious resolutions like 1440x900 and so on.
As soon as the resolution is available AGS should be able to use it.

- Alan

[Crimson Wizard]

On other hand, it may happen that windowed mode supports higher scaling than fullscreen.
For example, my display is 1680x1050, it can run 320x200 game on 1600x1000 (x5 filter) in window, but only 1280x800 (x4 filter) fullscreen.

Because you have to manually add that resolution to your drivers, I too have a 1680x1050 panel and my monitor sends an EDID to the drivers that lacks other obvious resolutions like 1440x900 and so on.
As soon as the resolution is available AGS should be able to use it.

- Alan

My driver does not support 1600x1000. (which is 320x200 multiplied by 5).

[Knox]

Will transparency on text window make the cut?

It is already there.

Do I have to set something up for it to work? Right now if I try using my semi-transparent text window sprites, Im still getting a screwed-up looking shadow:

Spoiler

[close]

Background color is black (I'm assuming that's what we need to set? I tried magic pink and that didn't change anything):

Spoiler

[close]

Spoiler

[close]

My sprites for the text window have been imported with alpha except for sprite #231, it is completly opaque and imported without transparency?:

Spoiler

[close]

[Crimson Wizard]

@Knox: it is in the code, but not in beta 8.

[Radiant]

Out of curiosity, would it be hard for this "max" scaling in windowed mode to maximize the window (so it covers the entire screen) and have a black border around the game area?

[Crimson Wizard]

Out of curiosity, would it be hard for this "max" scaling in windowed mode to maximize the window (so it covers the entire screen) and have a black border around the game area?

It is possible with custom display branch: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609
It is not finished properly yet.
There are too many things I started and I could not find time to get them all together.
That's really annoying...

[Radiant]

Ok, never mind then. Stable build comes first.

Last question: if a room's walkable areas are complicated and strung out enough, then moving from one end to the other will cause the pathfinding algorithm to eventually give up and move the character in the general direction but not towards the specified destination (e.g. make a W-shaped or WW-shaped zig zagging walkable, position player in top left corner and have him Walk() to top right corner). This strikes me as by design, because pathfinding would otherwise take up too much processor time, so it presumably stops after N interations for some constant N. So my question is, assuming it works this way, is the value of N something that makes sense for computers ten years ago, and should that value perhaps be increased for current computers to make pathfinding more accurate?

[Knox]

@Knox: it is in the code, but not in beta 8.

Ah gotcha!