AGS 3.3.0 Release Candidate

[Radiant]

Bug: changing the bundling type of the audio (sounds) folder from "in exe" to "in vox" doesn't change the bundling type of all individual sounds within that folder. There should be a way to do this centrally, without selecting each sound effect individually and changing them one by one.

[Crimson Wizard]

Bug: changing the bundling type of the audio (sounds) folder from "in exe" to "in vox" doesn't change the bundling type of all individual sounds within that folder. There should be a way to do this centrally, without selecting each sound effect individually and changing them one by one.

That's not a bug, that's lack of feature.
The type's property sais "DefaultType", and as all other default properties it is applied to all clips added afterwards, but not to the existing ones.
There probably could be an item in the context menu which changes the type, or maybe editor should allow to select multiple items and change their properties at once.

[Radiant]

I'm curious why anyone would want some sound effects in the executable and other sound effects in the audio.vox file?

Maybe the type of individual audio files should default to "inherit from folder" so that if you change DefaultType on the folder they will still use that.

[Crimson Wizard]

Maybe the type of individual audio files should default to "inherit from folder" so that if you change DefaultType on the folder they will still use that.

That's a good idea.

Same for "Bundling type".

By the way, have you noticed that you can move your sounds to VOX with "Bundling type" property?

[Radiant]

Yes, but I'd have to do 200 sound effects one by one

We found an issue with the "max" filter. On windowed mode, it works fine; on full screen, however, it seems to pick the wrong resolution somehow. The desktop is 1920x1080, and in fullscreen it's trying to run 1280x800 (a different aspect ratio) and it places horizontal bars at the top and bottom, making the game appear squashed. That's one of the testers, anyway; on my screen it does work. I'm curious what method it uses to pick the "best" resolution at fullscreen?

(edit) Assuming the game runs in 320x200 or 640x400, it would make sense to prioritize screen resolutions that match this aspect ratio; I'm not sure if that's what happens.

[Crimson Wizard]

Hmm, well, that option does not applies resolution on its own, it chooses the max multiplier that fits in screen.
Therefore the resolution it will try to apply will be exactly (320x200) * N.
What happens next is other issue... sometimes engine may try to change resolution if it failed to apply chosen one. We have also received report that on some occasions the graphics driver automatically switches resolution: http://www.adventuregamestudio.co.uk/forums/index.php?issue=440.0

Some info could be seen in the log.

[Radiant]

Ok, here's the logfile from running fullscreen:

Spoiler

Adventure Game Studio v3.3 Interpreter
Copyright (c) 1999-2011 Chris Jones and 2011-2013 others
ACI version 3.3.0.1146

***** ENGINE STARTUP
Installing exception handler
Reading config file
Initializing allegro
Setting up window
Initializing game data
Game data file: e:/Data/Games/HQ/Demos/November2013/HQ3.exe

Initializing TTF renderer
Initializing mouse
Checking memory
Initializing speech vox
Initializing audio vox
Initializing keyboard
Install timer
Initialize sound drivers
Install exit handler
Initialize path finder library
Load game data
You'd Beta Shape Up
Checking for disk space
Initializing screen settings
Init gfx filters
Detecting maximal supported scaling
Applying scaling filter: StdScale4
Init gfx driver
Switching to graphics mode
Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1920 x 1080
Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)
Attempt to switch gfx mode to 320 x 200 (32-bit)
Succeeded. Using gfx mode 320 x 200 (32-bit)
Preparing graphics mode screen
Initializing colour conversion
Check for preload image
Initialize sprites
Set up screen
Initialize game settings
Prepare to start game
Audio is processed on the main thread
Checking replay status
Engine initialization complete
Starting game
Loading room 1
***** ENGINE HAS SHUTDOWN

[close]

[Crimson Wizard]

Heh, I forgot this version does not write real resolutions, but emulated ones. Anyway, this is irrelevant.

I think this problem should usually be solved by setting "enable side-borders" option in setup, which must be set by default for 320x200 games.
I now recall Ali mentioned the bug, which caused game to fail detect when side-borders actually needed.

This log entry should not be there, it means the engine failed to detect a difference in ratios:

Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)

[Radiant]

You mean 'side borders on widescreen monitors', yes? I think it is enabled actually; it's not printed in acsetup.cfg but its default value is 'on' in winsetup.exe. We'll try forcing it by adding 'sideborders=1' to acsetup.cfg.

And that doesn't work. Omitting it, or setting it to 1 in the cfg file, gives "Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)", whereas setting it to 0 in the cfg gives "Widescreen side borders: disabled in Setup".

[Knox]

Not too sure if I should have put this here instead:

Everything works ok with alpha on the text windows, however I'm using the SSH's GuiPortrait v1.00 to display speech and it doesn't seem to work with that module (GSay function)http://www.adventuregamestudio.co.uk/forums/index.php?topic=34996.0...I also tested with the standard .Say funtion and the alpha doesn't seem to work either.

Gsay with GuiPortrait module (also standard .Say):


Normal text display works perfectly fine though since your last changes with Beta9:

[Crimson Wizard]

@Knox, sorry, I've read your post in other thread, but could not find time to look into this until now.

@Radiant, I changed how it detects the diff in the ratios, yet there's still not 100% guarantee the borders will be added, because this build requires resolution height to stay the same, so it all depends on what resolutions are supported.

Please, replace the engine: http://www.mediafire.com/download/3q6b28afpkyzced/acwin.exe

[Radiant]

I believe monitors have a function that enumerates display resolutions; wouldn't it help to simply use that? Then out of those, pick the highest supported multiple of the game resolution (if none, pick the highest supported multiple of the game's vertical resolution and the lowest corresponding horizontal resolution that still fits). Anyway, I've sent this off to the testers.

Incidentally, I'm getting this in my script now: "import int IntVar_Global_1;" as an automatically converted interaction variable. It doesn't seem to do anything, but what is it for?

[Crimson Wizard]

I believe monitors have a function that enumerates display resolutions; wouldn't it help to simply use that? Then out of those, pick the highest supported multiple of the game resolution (if none, pick the highest supported multiple of the game's vertical resolution and the lowest corresponding horizontal resolution that still fits).

But that is what it currently does.

Incidentally, I'm getting this in my script now: "import int IntVar_Global_1;" as an automatically converted interaction variable. It doesn't seem to do anything, but what is it for?

Hmm, maybe a forgotten global variable?

[monkey0506]

The IntVar_Global_1 is an artifact from projects imported from 2.72 to the 3.x branch of the editor. Unless you were using the 2.72 graphical interaction variables via the Interaction Editor then it can be safely deleted. You can check by just searching for "IntVar_Global_1". Likely the only usages are where it's defined, where it's exported, and where it's imported. I think this is created even if the project didn't have any graphical variables.

[Radiant]

But I never even used the interaction editor

[Radiant]

Anyway, the new version doesn't help this particular person; it goes to 1280x800 which the monitor does support but displays awkwardly. It seems to actually use a 1280x1000 mode and display the screen vertically centered, but I think it's the monitor hardware doing that, not the DX9 software. I'm not sure how else to solve this, other than by coding fullscreen mode as "windowed, but with the window maximized and some black padding between the game's size and the screen size"; I think that's how many 2D games do fullscreen these days.

[monkey0506]

But I never even used the interaction editor

But this was a 2.72 project originally?

I think this is created even if the project didn't have any graphical variables.

And there were definitely cases where using the Interaction Editor was unavoidable (e.g., any type of character, object, hotspot, inventory, etc. interactions), even if you just added a "Run script" interaction for those events.

[Knox]

@Knox, sorry, I've read your post in other thread, but could not find time to look into this until now.

NO problem Crimson! Thanks so much for your work. I tested the new acwin and it works perfectly! Yes!

[Radiant]

With the new build, we're occasionally getting this error which I'd never seen before: "error: Out of memory: failed to allocate 903224498 bytes (at PP=77)"

[Crimson Wizard]

With the new build, we're occasionally getting this error which I'd never seen before: "error: Out of memory: failed to allocate 903224498 bytes (at PP=77)"

Did it start to happen with beta 9, or after last engine update?
Do you have any crash dumps?