Common features: - Upgraded Windows version of AGS with Allegro v4.4 library (previously v4.2). - Implemented "RenderAtScreenResolution" game setting. When enabled, characters and objects are scaled in screen pixels rather than game pixels. (NOTE: it was always enabled for Direct3D in the past, but now you can set it to your liking) - Implemented VerticalOffset and LineSpacing properties for fonts. - Removed limit on Dialog Topics (was 500 topics per game). - Removed length limit on the names of Inventory, GUI and GUI Controls. - Removed length limit on the names of Hotspots and Objects. - Removed length limit on event handler names.

Editor: - Removed legacy game compiler. - Raw compiled game data is now saved in "Compiled\Data" folder, as opposed to just "Compiled". - The speech.vox file is now not recompiled if game is quick-run (using F5). Engine is supposed to find newer files in the Speech folder. - Editor can now import games older than 2.72, and newer too (3.*) if you have extracted data files from compiled executable. - ScriptAPIVersion and ScriptCompatibilityLevel settings now have "Highest" option, which is meant for automatically enabling newest script API when upgrading old project in a newer editor. - Added new "Default Setup" pane, which works similarily to "General Settings" and lets you configure default values for game setup. - Added "Font Height (pixels)" readonly property to the Font's pane, which works for both WFN and TTF fonts and may be used as a reference. - Made Editor correctly detect modern versions of MS Windows for display on About dialog and when sending anonymous statistics. - New application icon to comply with 3.4.0 splash screen. - Fixed crash when importing old games which have extended editor version string saved in the project files. - Fixed unhandled exception occuring when user types "#undef", "#ifdef" or "#ifndef" on the last line of the script. - Fixed #ifver and #ifnver not working properly if version number had only one component (major version). - Few improvements to the game compilation made in hope to reduce occasional data corruption.

Script: - Fixed local variables not working in the switch's case expressions. - Fixed Strings in switch, making them compare by value again. - Fixed compiler mistakes caused by the use of objects of empty type (that is - struct without any variables in it). - Fixed few cases of possible compiler crashing when there is an unfinished statement in the end of the script.

Engine: - Added OpenGL renderer to Windows version. - Added support for switching between fullscreen and windowed modes at runtime using Alt+Enter key combination. - All supported hardware-accelerated graphic drivers (Direct3D and OpenGL) now run every game in 32-bit display mode by default, and convert game's graphics on load if that is required. This fixes loss of green hue precision in 16-bit games and allows to run 8-bit games, although latter is only partially supported: there are color mismatches and dynamic palette cycling is not working. - Partial support for plugins drawing on screen for hardware-accelerated renderers (Direct3D, OpenGL). - Added support for global configuration file, which works as configuration for all games and overrides default game's config file. Individual game user's config overrides global one in its turn. Global config's location is platform-dependent (this feature is currently disabled on Windows). - Implemented separate config option for game's shared data path, to keep it distinct from user-defined saves path. - Engine saves last Windowed and RenderAtScreenResolution mode states to the user config file. - Engine no longer writes and reads gamma level in saves, meaning that gamma keeps its current value when restoring a saved game. - Removed arbitrary limit on number of sprites rendered at the same time for hardware-accelerated renderers (Direct3D and OpenGL) (was 75), and another limit imposed on drawing entries for all drivers (was 200). - Engine now tries to get voice files from the Speech folder first, if one exists, and speech.vox later when quick-run from the Editor. - Fixed speech portrait was displayed below GUI, contrary to speech text. - Fixed ShakeScreen command was causing graphic artifacts when game is run with software renderer. - Fixed calling Character.ChangeView during idle animation results in new view being animated. - Fixed Speech.SkipStyle getter return value for eSkipTime case. - Fixed Speech.VoiceMode not returning correct values when speech.vox is not enabled/present. - Fixed AdjustVolumeWithScaling character's property not working with the new audio system. - Fixed volume drop was not applied to audio clips which begin playing during speech voice-over. - Fixed Game.SetAudioTypeSpeechVolumeDrop did not affect currently playing clips until next voice-over begins. - Fixed Game.TranslationFilename returning "default" instead of empty string if no translation is set. - Fixed engine was trying to locate "My Documents" folder on Windows Vista and higher even though it did not need it, and reporting internal error if such folder was not found, even though "Saved Games" folder is used instead. - Properly toggle console upon play.debug_mode variable change in script. - Added missing stubs for agsjoy plugin.

WinSetup: - Fixed display mode selection was missing certain items.

KNOWN ISSUES (to be updated)

- Need to make mobile ports (Android, iOS) work with this version.- When using Direct3D, game misses 1 bottom row and 1 rightmost column of pixels of game image when "Render sprites at screen resolution" is OFF. This also might cause slight image distortion.NOTE: there's a suspicion that that is a bug in Microsoft's Direct3D driver since Windows 7.- When running game in OpenGL fullscreen system cursor may be visible when over black borders.

I wasn't sure if it was intentional or not, but the download links here:http://www.adventuregamestudio.co.uk/site/ags/ (http://www.adventuregamestudio.co.uk/site/ags/)...still have the previous stable version linked.

I wasn't sure if it was intentional or not, but the download links here:http://www.adventuregamestudio.co.uk/site/ags/ (http://www.adventuregamestudio.co.uk/site/ags/)...still have the previous stable version linked.

Is it true that OpenGL does not minimize when you alt+tab from fullscreen mode? Does anyone remember if this was always like this?

Following our discussion on another thread, I investigated that possible Alt+Tab issue and I was about to report this exact same problem.When in fullscreen, neither alt+tab nor Windows_key+D seem to work.In fact, they do (focus is lost), but the game stays on screen.

Quote

Also, now Direct3D crashes almost always when you alt+tab from fullscreen, saying "Present failed".

Also, it looks like there is some sort of "glowing" border around game in OpenGL, it is visible even during fade-out.

I saw this on Youtube videos but thought it was a video capture or encoding issue...

This only happens if "Smooth scaled sprites" is enabled. This is because program mistakenly counts the "fade effect" as a in-game sprite and "anti-aliases" its borders (or whatever OpenGL does in that case).

I have this small patch here (unofficial for now):https://www.dropbox.com/s/1qazws3bwr741q9/acwin--3.4.1-pre-patch1.zip?dl=0

* no longer crashes with "IDirect3DSurface9::Present failed" when you alt+tab from fullscreen Direct3D.* now minimizes OpenGL fullscreen mode when you alt+tab from it.* now the fade-out effects in OpenGL don't have "glowing" at the screen borders.

* no longer crashes with "IDirect3DSurface9::Present failed" when you alt+tab from fullscreen Direct3D.

Yes, this fix works for D3D...

Quote

* now minimizes OpenGL fullscreen mode when you alt+tab from it.

No. Not on my end at least. The game image stays on screen. The "windows" cursor appears on it but I'm not able to access the Windows environment... I'm forced to use ctrl-alt-del and then cancel to find that the game is minimized...But, I already reported an issue with alt-enter not going to windowed mode correctly for me with OpenGL. I suspect it's a related issue.

Quote

* now the fade-out effects in OpenGL don't have "glowing" at the screen borders.

Can't say because I did not see this effect myself before on my PCs...

What tips are there for building games through the Linux output, please, that fail because there is no "Linux" variant of plugins ie agsblend.dll ? (I can't quite remember the specific error wording at time of writing, something like "there is no linux equivalent, continue building?")

In this instance I think that particular plugin is non-critical, it's just there to minimize screen tearing or such. Of course, I'd rather it could build through Linux mode and keep these plugins in it. Should I contact the author? What if it is a critical plugin (integral to the structure/build of the game etc)

What tips are there for building games through the Linux output, please, that fail because there is no "Linux" variant of plugins ie agsblend.dll ? (I can't quite remember the specific error wording at time of writing, something like "there is no linux equivalent, continue building?")

In this instance I think that particular plugin is non-critical, it's just there to minimize screen tearing or such. Of course, I'd rather it could build through Linux mode and keep these plugins in it. Should I contact the author? What if it is a critical plugin (integral to the structure/build of the game etc)

Well, I'm just looking for advice on the best practices, thank you!

There are two separate issues here: compiling Linux version and running something compiled (even if for Windows) using Linux port.

Regarding compiling, this is a problematic case, because, unfortunately, AGS does not provide a way to turn some plugins off for particular build. So you will have that warning ("no Linux equivalent for plugin") all the time, sorry, unless you provide Linux plugin or turn Linux compilation off (except when you actually need it).

Regarding running, Linux port has some plugins integrated, I think AGSblend is one of them. So if you run the game on Linux, and engine won't find distinct plugin file, it will fallback to using integrated version.

Now, ideally, a plugin should be open sourced, and built for Linux (the *.so file), just like they are built for Windows (*.dll).In particular, AGSBlend is open sourced and available at our repository: https://github.com/adventuregamestudio/ags/tree/master/Plugins/agsblendIt even has a Makefile for linux, although I never tried building it myself.

To address the case of non-critical plugins. Unfortunately also, if you are using plugin API in script, game won't run without it, at all, because it requires all the API referenced in script to be implemented somehow.If there is absolutely no way for you to get Linux version of plugin, then there are two possible ways:

1) Compile a separate version of the game without plugin (with plugin functions commented out or disabled with #ifdef/ifndef commands in script).2) Create a plugin stub - that is a plugin that exports exactly same script API, but does nothing.

One other thing, can I check, at what point was a command called "switch" added please? Cos this has interfered with old code where we have ints called switch. Though I think I've fixed it by renaming our "switch" int to "switches", fingers crossed.

No. Not on my end at least. The game image stays on screen. The "windows" cursor appears on it but I'm not able to access the Windows environment... I'm forced to use ctrl-alt-del and then cancel to find that the game is minimized...But, I already reported an issue with alt-enter not going to windowed mode correctly for me with OpenGL. I suspect it's a related issue.

I tried it on another PC and it works. So it seems to depend on the system. I had the problem with 2 laptops... I'll try to test this on other PCs...

One other thing, can I check, at what point was a command called "switch" added please? Cos this has interfered with old code where we have ints called switch. Though I think I've fixed it by renaming our "switch" int to "switches", fingers crossed.

Switch was added at 3.4.0.Unlike new functions, keywords cannot be turned off though. But "switch" syntax is very specific, compiler will tell you where your variable is very quickly.

So I rebuilt the game through AGS 3.4.1, that's all I did, copy the compile folder over to a new folder and uploaded to Steam. Now we're getting a high number of "Avast" problems, with the EXE being flagged as a virus for many players.

I've read that Avast is a bit of a fecker when it comes to AGS EXE's. Do you have any suggestions? I honestly don't think the EXE itself has picked up any virus though it's not unfathomable.

I'm wondering if on Avast's end, they can see when an exe is getting used thousands of times, and then when a brand new version comes along, it assumes it's not been used before and insta-flags it or something.

Quote

avast advises they have moved the cat lady.exe to the virus chest because it was infected with filerepmalware. I did a scan but it showed up no malware

I read somewhere else that you say this is down to the GAME and not the ENGINE. But it's the engine that creates the EXE files so surely some of the problem lies there, though most of it may be with Avast and their overtly sensitive EXE shiznay. I don't personally use Virus software, to me it's a con. As such, it's not impossible it's picked up and packed in some kind of malware from my non-anti-virus computer but I mean...really? Malware can actually infect the internal EXE workings of an AGS game? How does that even happen? :/

Other note: No-one is saying this about the Doc Apocalypse EXE which is also built through 3.4.1, granted though that is going to have far few players than The Cat Lady's recent update built through 3.4.1. Point being, there is a slim chance of a real infection, but any up to date info about Avast issues you might know of would still be useful.

Thanks CW!

ps I'm not sure that anyone else has anything out (especially on steam or in public places) built through AGS 3.4.1 yet beyond us. If they have I'd be interested to know if they've had any Avast issues.

I have some questions.1) When will you have an executable for Linux? The current version is a text file and depending on whether the user has marked the option "open as executable" You can run the game or you will open the text file.2) When will the 2GB limit of the Acsprset.spr file be extended?3) Have you planned to modernize the AGS GUI?Otherwise I think AGS is on the right track.

1) When will you have an executable for Linux? The current version is a text file and depending on whether the user has marked the option "open as executable" You can run the game or you will open the text file.

I do not understand your question. There are executables for Linux, available with the installer, or as a separate package (in the first post). What "text file" are you are talking about?

So I rebuilt the game through AGS 3.4.1, that's all I did, copy the compile folder over to a new folder and uploaded to Steam. Now we're getting a high number of "Avast" problems, with the EXE being flagged as a virus for many players.

I've read that Avast is a bit of a fecker when it comes to AGS EXE's. Do you have any suggestions? I honestly don't think the EXE itself has picked up any virus though it's not unfathomable.

I'm wondering if on Avast's end, they can see when an exe is getting used thousands of times, and then when a brand new version comes along, it assumes it's not been used before and insta-flags it or something.

There were a lot of cases of Avast false alarms, and I even tried getting some info from them once: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54963.msg636564726#msg636564726but later seem to forget about that.

1) When will you have an executable for Linux? The current version is a text file and depending on whether the user has marked the option "open as executable" You can run the game or you will open the text file.

I do not understand your question. There are executables for Linux, available with the installer, or as a separate package (in the first post). What "text file" are you are talking about?

It is the script that launches the executable, but it doesn't have the execute bit sethttp://www.adventuregamestudio.co.uk/forums/index.php?topic=54571.msg636557425 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=54571.msg636557425#msg636557425)

Okie doke. Hopefully a false alarm then... not sure I can do much about it (their false positive form only allows a pithy 50mb EXE). thanks for the note!

I actually have a suggestion: try to distribute "raw" engine exe with game file (*.ags) taken from Compiled/Data folder, instead of Compiled/Windows.This may be bit inconvenient in regards to preparing a package, also you would have to manually change game icon in exe.

I believe there may be a need of an option to create Windows version same way as Linux one - with engine exe separate.

It is the script that launches the executable, but it doesn't have the execute bit sethttp://www.adventuregamestudio.co.uk/forums/index.php?topic=54571.msg636557425 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=54571.msg636557425#msg636557425)

Oh, its the script that AGS Editor creates on compilation. I forgot it does one.

Thanks! But yes I'm a bit confused... In my Compiled folder I've got my compiled game. In my Windows folder I've got my compiled game. In my data folder I've got some of my compiled game... And what is that game.ags file? Are you saying that .ags file needs to be distributed as well? It's not in my standard Compiled folder or my Windows folder though, just the Data one. And where should I be taking my game files from? I'm taking them from "Windows" currently and ignoring the root Compiled folder. (admittedly I might have copy+pasted the contents of windows to the root folder myself) ??? Anyway, I might just try the breaking game into chunks option and send the small EXE to their Whitelisting thingy. God I hate avast.

.ags file is the game content minus the engine executable (it's the raw file which is then used to create the Windows version and the Linux version)In the Windows folder, the .exe is the engine + the data files.

The usual way to run the game in Windows is to directly use the game .exe file. But you can also copy acwin.exe (the game engine) from your Program files\AGS... folder in the folder containing the .ags file and acwin.exe will run the game using the .ags file.In this last case, if you want to run the setup, run "acwin.exe --setup".

Thanks! But yes I'm a bit confused... In my Compiled folder I've got my compiled game. In my Windows folder I've got my compiled game. In my data folder I've got some of my compiled game... And what is that game.ags file? Are you saying that .ags file needs to be distributed as well? It's not in my standard Compiled folder or my Windows folder though, just the Data one. And where should I be taking my game files from? I'm taking them from "Windows" currently and ignoring the root Compiled folder. (admittedly I might have copy+pasted the contents of windows to the root folder myself) ???

Ok, to elaborate.Before 3.4.0 the structure of files in Compiled folder was very simple: only Windows version, made as bundled exe.

In 3.4.0 the Compiled folder itself keeps intermediate output which includes non-bundled "raw" game data, usable with any port (including Windows), and Compiled/Windows folder includes specifically Windows version.

In 3.4.1 we cleared things up by moving unbundled data into Compiled/Data, and Compiled folder itself is supposed to stay clear of any files.I.e.:

* Compiled/ -- no files here, only subfolders* Compiled/Data - raw game data, usable with any port if you add port's executable. Also, you may add some custom data files there, and they will be copied around to Windows, Linux etc versions.* Compiled/Linux - game data combined with Linux binaries* Compiled/Windows - game data bundled with Windows binaries

All this is explained in the manual, BTW, the topic is named "Distributing your game", also may be found by keywords "Compiling the game".

If you have upgraded your game from 3.4.0 to 3.4.1, you may have old files remaining in just Compiled folder that you can just delete. Unfortunately at the time being I was not able to invent a proper way to clean things up automatically. The problem is that this folder may contain user files, that is files that user put there themselve, and moving them somewhere could not be wanted. There might be some simple way to solve this, but... perhaps in the future update.