AGS 3.4.1 - Early BETA

Started by Crimson Wizard, Wed 08/02/2017 00:35:53

Previous topic - Next topic

Crimson Wizard

After 3.4.0 was released we decided that releases should be made more often, and after several months passed we should just gather what we have made and publish that as a new version.

What I am posting here is a relatively "raw" early beta version of 3.4.1. This is why I am not making this as a "proper" beta release yet, but as some kind of pre-beta, meant for public testing.
When we find and fix serious problems, I will feature-freeze it and release it more officially.
Speaking of features, they may still be added as testing goes on, but I would not count on that much. Personally I would like to focus on getting existing things to work correctly as a first priority.

Feature-wise this 3.4.1 release is going to be rather small, especially compared to the gigantic 3.4.0 list. Personally I spent most of the time refactoring the code and improving some internal functionality; if not for other contributors the list would be half as small.


Uploaded AGS 3.4.1 - Early Beta 2:

Download as ZIP archive

Mirror:
Download from Mediafire

Please, remember this is still a non-stable release, intended for tests only. Use at your own risk.


This release is brought to you by:

- Alan v. Drake
- Crimson Wizard
- Gurok
- monkey0506


What's new in 3.4.1

Common features:
- Upgraded AGS with Allegro v4.4 library (previously was Allegro v4.2). Now Windows version works with same library as all other ports (Linux etc). This is experimental at this point, so watch out for any weirdities (although hopefully there should not be any). From my knowledge, the primary effect should be fixed Alt key, but that requires testing.
- Implemented "RenderAtScreenResolution" game setting. When enabled, characters and objects are scaled in screen pixels rather than game pixels, which can make them look more hi-res than the rest of the game. In the game project this property has following values: Enabled, Disabled, User-defined. The first two lock the scaling to respective style. The last one enables a checkbox in the winsetup which lets player to adjust this setting to their liking.
  Currently this mode works only in Direct3D. OpenGL renderer (on Android and iOS) had its own setting for the long time, but at the moment it is not connected, which is something to be fixed.
- Fonts now have VerticalOffset property (per each font separately). This is a number of pixels by which any line of text should be moved either up (negative offset) or down (positive offset). This is a workaround for some TTF fonts not aligned properly when drawn on screen in game. Note that this property works for all fonts, just in case.
- Implemented LineSpacing property for the fonts. This lets you set up default spacing for every font. Value is in pixels, and determines how much the Y coordinate should increase before printing next line of text. "0" has special meaning that makes AGS use font's height for spacing (which is also backwards-compatible).
  NOTE: line-spacing is not a distance between bottom of first line and top of second, but distance between top of first line and top of second.

 
Editor:
- Removed old game compiler. Most of 3.4.0 users are now using new one anyway (probably most people do not even know what's the difference and how to switch between them), and there was only one serious bug found in the new one, which is already fixed.
- Compiled game data is now first saved to "Compiled\Data" folder (before being copied to "Compiled\Windows", "Linux" and so on), as opposed to just "Compiled". This will supposedly make folder structure cleaner. Now if you want to ship any custom files with your game, add them to "Compiled\Data" and they should be included into every version.
- Editor should now import games older than 2.72, and actually newer too (3.*), if you have extracted data files from compiled executable. This should be tested, but will work in theory. This change will make it unnecessary to import pre-2.72 projects to 2.72 before loading them up in latest editor.
- ScriptAPIVersion and ScriptCompatibilityLevel settings now have "Highest" option, which is meant for automatically enabling new script API when loading old project in a newer editor. Previous versions of AGS (before 3.4.0) did this naturally, but with introduction of those two API switches, it is possible to "lock" your project at certain API level by selecting particular variant for those properties. Usually you'd want to have both on Highest now, only changing them if you need to compile old scripts.
- Added new "Default setup" panel, which works just as "General Settings" and lets you configure default options of game setup. Currently the page is rather a dummy, with just couple of options available, but more could be added later.
- Added "Font Height (pixels)" readonly property to the Font's pane, to be used as a reference (e.g. when setting LineSpacing).

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

Script API:
- Stopping movement is now optional when (Un)LockView functions are called. A new parameter StopMovementStyle is added to following functions: LockView, LockViewAligned, LockViewFrame, LockViewOffset, UnlockView. This parameter can be eStopMoving (default) or eKeepMoving.
- Added missing readonly properties to get Lighting/Tinting parameters for Character and Object: HasExplicitLight, HasExplicitTint, LightLevel, TintBlue, TintGreen, TintRed, TintSaturation, TintLuminance.
- Added Mouse.SelectPreviousMode() and Mouse.IsModeEnabled(CursorMode) functions.
- Added readonly properties to get Button's animation state: Button.Animating, .Frame, .Loop, .View.
- GetFontHeight(FontType) and GetFontLineSpacing(FontType) script functions.


Engine:
- AGS supports switching between fullscreen and windowed modes at runtime using Alt+Enter key combination. Note: functionality may currently be buggy and requires testing & fixing.
- AGS now supports "global config", that is config for all games. This was added by request of Linux users, but also works on Windows (although currently you can only create and edit it by hand). Idea is that AGS reads 3 config files, with every next file overriding matching settings from the previous ones:
  * acsetup.cfg located in the game's folder (default config);
  * global config
  * writable per-game config
  The location of configs depends on system:
  Linux:
    >> user's global config: $XDG_DATA_HOME/ags/acsetup.cfg
    >> user's game config: $XDG_DATA_HOME/ags/GAMENAME/acsetup.cfg
  Windows:
    >> user's global config: %USERPROFILE%/Saved Games/.ags/acsetup.cfg
    >> user's game config: %USERPROFILE%/Saved Games/GAMENAME/acsetup.cfg
- 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 (since 3.2, I guess).
( -- something unusual -- )
- AGS now won't read gamma level from the saved game, which means that if you altered gamma slider and then restored previously saved game, gamma should stay the same. The reasoning behind this is that display's gamma is exclusively a user setting rather than part of the game. There is a caveat however: if gamma is controlled by GUI slider, slider will get its position from the save game, meaning that it should be corretly scripted to update from actual gamma value upon game restoration. Of course this will make things tad more complicated for game developer, and also break existing games if they are run on a new engine, but this was a choice in dilemma between having a temporarily desynchronized gamma slider (it will sync back as soon as player touches it), and annoyed player who changed gamma and suddenly gets it back whenever restoring an older save. I am open for suggestions how to improve this, if there will be any.


Mehrdad

#1
Thanks a lot CW and others for this great roadmap

In first of run game I had an error that I sent it online to your server.


I always had big problem with fonts in AGS . My native language is Persian and AGS doesn't support it as ttf :

For ex: ' Today is rainy'
Right Persian text is : ' امروز هوا بارانÛÅ' است '
Result in AGS : ' ? ? ? ? ? ? ? ? ? ? '
I tried some Persian convertor and final result in best method was : ا Ù… ر Ùˆ ز Ù‡ Ùˆ ا ب ا ر ا Ù† ÛÅ' س ت

AGS doesn't Unicode TTF fonts support. And it's awful typing as custom fonts with custom keyboard .

I made all Persian font characters with Unicode numbers for you :
https://www.dropbox.com/s/l7m7nvt7yfb5419/PersianAndUnicode.rar?dl=0 

I know it takes many times for you . If you have any other suggestion for this issue (without use GUI) I'll glad to see it.

Many Thanks
Mehrdad
My official site: http://www.pershaland.com/

Crimson Wizard

#2
Quote from: Mehrdad on Wed 08/02/2017 07:20:52
In first of run game I had an error that I sent it online to your server.
I do not have access to that server data, I do not even know where it is, and who owns it.

Quote from: Mehrdad on Wed 08/02/2017 07:20:52
I made all Persian font characters with Unicode numbers for you :
https://www.dropbox.com/s/l7m7nvt7yfb5419/PersianAndUnicode.rar?dl=0 

I know it takes many times for you . If you have any other suggestion for this issue (without use GUI) I'll glad to see it.

I do not know what to do with this, sorry. We need proper Unicode support in AGS. I can tell absolutely for sure that I won't work on that right now. Such job may take months, and I want to release this version as soon as everything works stable.

Mehrdad

My official site: http://www.pershaland.com/

Vincent

Many thanks to Crimson Wizard and to all the people who worked on this early beta version.
Now I can't wait to test it out properly.
Many thanks guys again for the hard work you have done together.

Quote from: Crimson Wizard on Wed 08/02/2017 00:35:53
The reasoning behind this is that display's gamma is exclusively a user setting rather than part of the game.

If there is a way to make this fact the other way around would be ideal of course (I think).
So to make it exclusively a part of the game and the player can altered gamma only controlled by a GUI slider otherwhise it display his default value anytime. I think it could be scripted properly from the game developer to update the actual gamma value upon a game restoration (It might not be so nice to do in this way but if it can be the only solution to solve this issue then it's just okay).

Dave Gilbert

Sweet! A new version!

Will download soon and see what's what. Thanks again.

Crimson Wizard

#6
Quote from: Vincent on Wed 08/02/2017 11:58:50
Quote from: Crimson Wizard on Wed 08/02/2017 00:35:53
The reasoning behind this is that display's gamma is exclusively a user setting rather than part of the game.

If there is a way to make this fact the other way around would be ideal of course (I think).
So to make it exclusively a part of the game and the player can altered gamma only controlled by a GUI slider otherwhise it display his default value anytime. I think it could be scripted properly from the game developer to update the actual gamma value upon a game restoration (It might not be so nice to do in this way but if it can be the only solution to solve this issue then it's just okay).

It WAS other way around, and that is something that I wanted to change.

If Gamma is a part of the game, and stored in saved game, and then loaded back, then the Gamma value that player set before loading that game will be LOST. And the slider's position will be lost too. And there will be no way to script the game to return it.

What happens now in AGS is that if you changed gamma in your game, and then decided to load previously saved game, then your gamma will return back to old value, and you have to set it to wanted position again. And again, and again -- every time you load old save.

Gamma is a part of system settings - same as display resolution, windowed/fullscreen setting, and so on: something that should not be changed when an old save is loaded.

Vincent

Okay I get it.
Currently there is no way to save the value of the Gamma and load it properly with a saved game.

Crimson Wizard

#8
Quote from: Vincent on Wed 08/02/2017 14:01:34
Currently there is no way to save the value of the Gamma and load it properly with a saved game.
No... Quite opposite, what I am trying to say, that I do not want to load it with a saved game, because if you do that, it will be lost, overwritten by value from saved game.

Existing versions of AGS load it from saved game. This is what I changed.

EDIT: Actually, I am not sure anymore that I understand what you mean too....

EDIT2:
To clarify things again:

NOW
Gamma value is written into save, and loaded back from restored save.
Why is that bad, in my opinion? Because it may change screen brightness for player when they load saved games, which IMO makes no sense.

MY CHANGE
Gamma value is NOT written into save, but kept the same.
What problem may that cause? If there is a Gamma slider in the game, its position will load from the save, but since gamma is not taken from save anymore, that slider's position may be different from actual gamma.
How this may be solved? Game developer must make sure to update slider upon game restore, simply doing "slider.Position = System.Gamma".

Vincent

Okay, I realized now. I was a bit confused as my usual. :)
After all, I believe it is a right choice that make sense.

Perhaps it would be right if there was a way to choose both ways to define the value of the gamma.
You can restore his value from a saved game otherwise from the system setting.
I am not sure if this is possible and how it can be convenient to do so.

selmiak

cool, lots of useful changes and additions :)

- Implemented "RenderAtScreenResolution" game setting. When enabled, characters and objects are scaled in screen pixels rather than game pixels, which can make them look more hi-res than the rest of the game. In the game project this property has following values: Enabled, Disabled, User-defined.
this is especially useful. what about splitting the last option to: User-defined On / User-defined Off
and I don't mean to turn this checkbox on or of but to set if the checkbox is checked or not as a default value from exatly this gamesetting option.

cat

Just edit the settings file you ship with the game ;)

Crimson Wizard

#12
Quote from: Vincent on Wed 08/02/2017 14:44:16
Perhaps it would be right if there was a way to choose both ways to define the value of the gamma.
You can restore his value from a saved game otherwise from the system setting.
I am not sure if this is possible and how it can be convenient to do so.

It is technically possible, but with all honesty I do not see why this may be needed.


Quote from: selmiak on Wed 08/02/2017 14:50:42
what about splitting the last option to: User-defined On / User-defined Off
and I don't mean to turn this checkbox on or of but to set if the checkbox is checked or not as a default value from exatly this gamesetting option.

We were considering this at first, but later decided to go simply with "User defined", because default value can be set in config file that is distributed with the game.
EDIT: well, basically what cat said.

selmiak

I didn't know it was discussed already, I just had the thought it would be easier to quickly change it this way rather than compiling the game and opening gamesetup.

Dave Gilbert

#14
One very minor niggle. While in full-screen mode, booting up and quitting the game both seem to take several seconds longer then they used to. Around 5-10 seconds. I remember encountering this when I tested out your alt-enter version of the engine, so that may be related.

Crimson Wizard

Quote from: selmiak on Wed 08/02/2017 21:41:07
I didn't know it was discussed already, I just had the thought it would be easier to quickly change it this way rather than compiling the game and opening gamesetup.

Perhaps means to set all default config from the editor would be useful. Right now you can set only default renderer.

Quote from: Dave Gilbert on Wed 08/02/2017 23:11:09
One very minor niggle. While in full-screen mode, booting up and quitting the game both seem to take several seconds longer then they used to. Around 5-10 seconds. I remember encountering this when I tested out your alt-enter version of the engine, so that may be related.

I cannot think of anything in particular... except in the past many objects were not properly deleted before exit and memory just cleaned up by operating system.
But 5-10 seconds? I cannot remember any game exiting so long. If that really takes so much, I would like to try doing profiling when running your game under debugger, to see which operations take most of the time.

cat

Quote from: Crimson Wizard on Thu 09/02/2017 00:38:13
Perhaps means to set all default config from the editor would be useful. Right now you can set only default renderer.

This might actually be a good idea. At the moment, it is a bit confusing how to properly prepare the config file for shipping. There are several config files lying around in the directories and are copied during compile. And when you open the winsetup, actually your local user files is edited. It gets more complicated when you then use special config values like a name for the default language.

Crimson Wizard

Quote from: cat on Thu 09/02/2017 09:14:16
This might actually be a good idea. At the moment, it is a bit confusing how to properly prepare the config file for shipping. There are several config files lying around in the directories and are copied during compile. And when you open the winsetup, actually your local user files is edited.
Whoops, I forgot about that.
That should not be too hard to add another section to the General Settings, or create a separate pane of same style for "Default Config".

Dave Gilbert

Quote from: Crimson Wizard on Thu 09/02/2017 00:38:13
I cannot think of anything in particular... except in the past many objects were not properly deleted before exit and memory just cleaned up by operating system.
But 5-10 seconds? I cannot remember any game exiting so long. If that really takes so much, I would like to try doing profiling when running your game under debugger, to see which operations take most of the time.

Sure. Sorry to sound dense, but how do we go about doing that? Is that something I do on my end or yours?

edit: I tested quitting the game in windowed mode and it was instant. It only takes a long time in fullscreen mode.

Crimson Wizard

Quote from: Dave Gilbert on Thu 09/02/2017 10:50:50
Sure. Sorry to sound dense, but how do we go about doing that? Is that something I do on my end or yours?

Ideally, I could test your game on my PC with debugger and/or profiler (the tool that calculates process speeds).

Other than that, I could make a special version that writes times of operations to the log file, and let you run it.

SMF spam blocked by CleanTalk