Adventure Game Studio | Forums | Show Posts

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Topics - Crimson Wizard

Pages: [1] 2 3 ... 11

Engine Development / How should a proper audio system look like?

« on: 19 May 2018, 15:17 »

First of all, I'd like to ask to not assume that me, or anyone else, will jump into doing this right away (this is to prevent premature expectations).

It's well know to anyone who has every worked with contemporary AGS audio system, that its design is somewhat lacking (to say the least), causes lots of confusion, and feels clunky even if you know how it works.

There is an issue with unreliable audio clip index, which make it impossible to reference particular clips when using a formula or saved data (without creating additional arrays to store clip pointers in the wanted order). I am still aware of that, but personally think it's a separate issue, more related to resource organization in game (you will have same problem with any other item in game, such as characters or views).

What I'd like to discuss is, what a good audio API should be.

In the past there was a suggestion to introduce new type, something like "AudioPlayback", which is returned from AudioClip.Play instead of the channel. By assumption, that would reduce the problems people have when storing AudioChannel pointer for a long time, which may later get other clip played on it. Is it a good idea?

Other questions that come to mind, if there are properties that control sound, such as speed, volume, and so on, should they be a property of AudioPlayback or a channel? Should the user be able to set up a volume of the channel, perhaps?
Should channels be created by user in the project tree? If yes, then should there be a general list of channels, or channels per audio type?

Even if you cannot or do not want to consider how this should look like in script, from the user's perspective, what would you like to be able to do there, what items or parameters are essential to control for a game developer?

PS. I know that tzachs is designing an audio system in MonoAGS too, although he took the abstraction further compared to AGS. For example, in his system there is no such thing as "audio type", instead there are "tags" which are used to setup rules for playing a clip, such as how to choose a channel, and so on. While that approach is more flexible, idk if it will be used often to full degree. AGS could have simplier built-in behavior, but provide sufficient API to let users script their own playback rules. For example: let user to explicitly set clip to the particular channel.

AGS Engine & Editor Releases / AGS 3.4.1 - Patch 2 -- latest STABLE version

« on: 13 May 2018, 20:30 »

AGS 3.4.1 - Patch 2 released

Current release number: 3.4.1.13

*** Download as installer ***

*** Download as ZIP archive ***

--- NO-MP3 engine variant ---

Linux build package (Editor component) as ZIP archive

For Android

Add spoiler tag for Hidden:

For developers

Add spoiler tag for Hidden:

Released: 13th May 2018

Previous stable version: AGS 3.4.0 forum thread

This release is brought to you by:

- Alan v. Drake
- ChamberOfFear
- Crimson Wizard
- Gurok
- monkey0506
- Ryan O'Connor (one bug fix contribution)
- Scorpiorus (improvements to plugin drawing system)

And artists of the new Sierra-style template:
- CaesarCub
- Hobo
- Jim Reed
- ProgZmax
- Selmiak

Changes in the Patch 2:

Templates:
1. Now includes new "Sierra-style" template which substitutes elderly "Default" template and contains new age graphics.
Template topic: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54703.0
2. Made small fixes to the Verb Coin template to make it compatible with 3.4.1 out of the box.

Editor:
- Font's line spacing and offset are now used when displaying GUI previews.

Engine:
- Removed limit on maximal asset files in a game package. (Now you may have over 10k voice files in speech.vox)
- Fixed game refused to start at all if speech.vox has bad format.
- Fixed DynamicSprite.SaveToFile() was not appending default "bmp" extension if user did not specify one.

Android:
- Updated port to work with 3.4.1 engine. Software renderer works again too (was broken in 3.4.0).

Changes in the Patch 1:

Engine:
- Removed game error reported when GUI coordinates were off the room limits.
- Fixed crash in Direct3D renderer when alt+tabbing out of fullscreen mode.
- Fixed OpenGL fullscreen mode was not minimized when you alt+tab from it.
- Fixed Direct3D and OpenGL renderers unnecessarily applied anti-aliasing on utility sprites (used for transition effects) when "smooth scaled sprites" option was enabled.

What is new in 3.4.1

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.

Script API:
- A new parameter StopMovementStyle is added to following functions: LockView, LockViewAligned, LockViewFrame, LockViewOffset, UnlockView. This parameter can be eStopMoving (default) or eKeepMoving.
- DynamicSprite.CreateFromFile and SaveToFile now support path tokens and comply to the new file path rules (no writing files to the game's installation directory).
- 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, Button.Frame, Button.Loop, Button.View.
- Added GetFontHeight(FontType) and GetFontLineSpacing(FontType) functions.
- Added setter for System.Windowed property, letting to change it at runtime, switching between windowed and fullscreen modes.
- Added System.RenderAtScreenResolution property to change sprite rendering mode at runtime.

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.

Site & Forum Reports / Updating online manual

« on: 09 Apr 2018, 10:45 »

Alright, since my post in the other thread was kind of hidden by discussing changes to wiki, I will repost the issue separately.

So, after AGA gave me permissions (or maybe I had them before, idk), I tried to upload new manual content to the website, but some issues were found, so I had to revert.

1. Pages on website use styles from external css file. While pages generated in repository have embedded css, and they are different (background, font, etc).
2. Pages on website have some additional script for toolbar display.
3. Website manual has additional html pages for contents, index etc. Manual in repository does not generate html pages for these. This means that even if I upload new topic pages, the contents tree will remain 3.2.1, and links won't match.

Would it be possible to find out who have created this online manual, and how?

For the reference:
Existing manual (corresponding to AGS 3.2.1): http://www.adventuregamestudio.co.uk/manual/
Archive containing both versions of html pages for comparison: https://www.dropbox.com/s/v958t0938w76cyk/AGS--manualpages.zip?dl=0

General Discussion / Asking for an advice on finding a gamedev job

« on: 04 Apr 2018, 22:57 »

I was not sure how to best put this, so the post may be bit awkward. But I wanted to ask for an advice.

Back in 2016 I quit my office job because of AGS... partially hoping that would let me improve situation with the project, and partially because of stress. Probably I was not thinking straight, because it was AGS that caused all the stress. Some time later it became fully clear that the project is going nowhere, and I decided to return to the old job, but did not manage to stay on it for long. Don't know why exactly, but I literally was not able to get any kind of satisfaction anymore. I was constantly stressed out, and even being in the office with other people around made me frustrated. So after six months I quit again.
Since then it is about a full year as I am officially unemployed. During this time I participated in a small commercial project for couple of months, and was able to get some money, but quit eventually too, partially because AGS and related stuff still dominated my thoughts. It was the time when 3.4.1 was supposed to be released, and I could not stop thinking about that.
That took too much time to break away from this project that drained me from all the energy, and now I begin to realize something that was bothering me subconsciously these years. The thing is, I no longer could answer why I was even working on it all the time. This is not what I wanted to be doing. I remember dreaming of making games, not recoding someone else's engine for six years.

I fear this could have been a terrible mistake for me. I could have spent those six years learning contemporary engines and game development, instead I spent all that time for something that is barely useful anywhere else.

Right now I must be searching for a real job again and keep wondering would it be possible to find one in game development. The problem is, on one hand, that it does not anymore seem a good idea to just get a "normal" office job while trying to practice game projects in a free time. I'm afraid that would just cause more frustration, and I'll loose several years more without any achievement. On another hand, I have barely anything to "showcase", after spending years on AGS engine I was too stressed to actually work on any game, and just afraid that I won't be able to handle another work simultaneously. So this makes a stupid dilemma.
There are few projects I worked on in the past, which were kind of finished in the past, which could be mentioned just to give an idea, but idk if that means anything.

Add spoiler tag for Hidden:

Today I would not even know what or where to begin with to start searching for any game-related jobs. Are there any sites or communities where one could find a job for someone with limited gamedev-specific experience?
Another issue is money... in the past I was involved in couple of game projects where I was supposed to be paid in the end, but unfortunately these projects never reached the point at which anything could be earned. I'd really rather not become a part of a game with vague perspectives again, at least not now.
So, frankly, how realistic that may be to get a position in a project with guaranteed payment in a sensible time period, like being paid monthly (even if a little bit), or at least once during the course of the year?

Adventure Related Talk & Chat / The benefits of walk-behind masks vs multilayered setting

« on: 10 Mar 2018, 20:47 »

Hello.

I am very curious about whether classic walk-behind masks has any practical advantage, even if in particular situations, over making multi-layered rooms (e.g. using objects). And whether such advantage is related to how AGS deals with masks (specific to workflow).

The main reason I am asking is that I noticed that tzachs's new developed engine supports walk-behind masks as an option, although the engine itself has 3d-texture rendering, so this seem to be a support of "legacy method" rather than actual necessity. So this is both a concern and curiosity on my side (not a big deal, but supporting extra features means spending extra effort).

AFAIK, the origin of this method comes from peculiarities of software rendering and system limits of old times. Walk-behinds could be used to optimize drawing a bit, and also save some space both on disk and memory.
But in a contemporary engine which uses textures it has zero advantage over adding extra layer to the room (as an object of sorts): it still has to be a separate texture to be drawn above characters.
Even in AGS, when you run game with Direct3D or OpenGL renderer, the engine "cuts out" the "walk-behind" piece of background onto a separate image, partially duplicating room image in memory.

So, there is seem to be no benefit from the program's or perfomance perspective anymore.

Is there any benefit from game designer's or artist's perspective?

I don't have much experience here, so my view on this is mostly speculative. One good thing about walk-behind maks I know is that you can make one fast assuming you have a right tool to do so , which may be useful if you are prototyping room with a flat background. On the bad side, annoying thing about masks is that you have to constantly keep it updated with background graphic: if an object on background changes in shape even by a pixel - the mask has to be synchronized again; so this might be counter-productive in the long run. Another thing is that walk-behind masks don't work with antialiasing or half-transparency.
In the abscence of a tool that allows you to draw masks and save them in engine's format, you would have to keep mask as a separate image (or as a layer in your background image document), so you are having multiple images anyway.

What is your view on walk-behind masks?

AGS Engine & Editor Releases / AGS 3.4.2 - alpha 2 - next WIP version

« on: 21 Feb 2018, 13:52 »

AGS 3.4.2 - Alpha 2

Download 3.4.2 (Alpha 2) as a .zip archive
Download Dark UI Theme for the editor

AGS source code central repository

ACHTUNG!

This is a development version of AGS 3.4.2.
Use at your own risk. Please back up any games before opening them in this version of AGS.
New settings in this version may make your project files unusable in previous versions after saving with this version.

Last updated: 20th of May, 2018
Has all content from AGS 3.4.1.13.

This release is brought to you by:

- Alan v. Drake
- ChamberOfFear
- Crimson Wizard
- Martin Sedlak (new pathfinding)
- morganw
- tzachs

What is new in 3.4.2

So far this update is mainly focused on improving the Editor's UI and tidying some things in the engine.

Editor:
- Editor requires .NET Framework 4.0 to run.
- Editor preferences are now stored using .NET configuration model, instead of the Windows registry.
- Added support for custom UI color themes.
- New navigation bar in the room editor, which allows to select any room object or region for editing, show/hide and lock room objects and regions in any combination.
- Added "Export mask to file" tool button to the Room Editor.
- Added "Always"choice to "Popup message on compile" preference. Successful compilation popup will only be displayed if "Always" choice is selected.
- Added shortcut key combination (Shift + F5) for stopping a game's debug run.
- Don't modify filesystem permissions in Compiled directory when compiling the game.
Editor no longer requires non-standard "takeown.exe" utility.
- Corrected .NET version query for the anonymous statistics report.
- Fixed sprite folders collapsing after assigning sprite to a View frame or an object.
- Fixed view loops displayed with offset if the view panel area was scrolled horizontally prior to their creation.
- Fixed TextWindow GUI's elements could be deleted or moved in the editor with key controls.

Engine:
- New pathfinder based on the A* jump point search.
- Implemented new savegame format. Much cleaner than the old one, and easier to extend, it should also reduce the size of the save files.
The engine is still capable of loading older saves, temporarily.
- Expanded some of the error messages providing more information to end-user and developers.
- On Linux improved CPU yield function, this supposedly may reduce CPU usage.

Windows:
- Windows version of AGS is now built with MSVS 2015 and higher.

On color themes

After launching the Editor, go to File - Preferences. In the "Editor Appearance" group box you will find "Color Theme" setting. If you haven't installed any themes yet the selection list will be empty. Press "Import Color Theme" and select appropriate JSON file, containing theme configuration.
Sample color theme: Dark UI Theme.

There is no specification on theme creation yet, but I hope there will be one at some point. For now you may copy and modify existing one. Themes are in JSON format, which you may edit in most simple text editors. If the theme is broken, the editor will report an error and reset to Default theme on startup.
ChamberOfFear also suggested creating a repository for the themes to let people upload their own and improve existing ones, which we may do in a future.

On new navigation bar in the room editor

This was made by tzachs back in 2014, but got into the editor only now. The feature is working, but may need polishing.

Screenshots (warning - big size):

Add spoiler tag for Hidden:

Quoting tzachs (from his old thread) -

- Room Layers

This feature allows you to view (and edit) walkable areas/walk-behinds/hotspots/regions/characters/objects/edges in the same time (as opposed to only seeing one of them at a time, like we've seen before).
Well, not entirely though: walkable areas/walk-behinds/hotspots/regions still can't be seen together (as they use masks and is part of the natives dll so I skipped it for now) but they can be seen along objects, characters, and edges.

- Visibility

Each layer can be made visible/hidden by the push of a button. In addition, for the objects/characters/edges layers each item in the layer can also be made visible/hidden by the push of a button. This will only affect the editor, not the actual game.

- Locking

Each layer can be locked/unlocked by the push of a button. In addition, for each layer, each item in the layer can also be locked/unlocked by the push of a button.
A locked item cannot be moved until it is unlocked, useful to prevent mistakes when designing the room. This will only affect the editor, not the actual game.

On savegame format

AGS 3.4.2 introduces new savegame format. This had to be done for several reasons, mostly internal ones, because existing format was too difficult to maintain and expand.
From the user's perspective, the notable change is that save file will be somewhat smaller, because redundant data is no longer written there (I did some tests in the past, and iirc depending on circumstances the size reduction was about 20-40%, but this awaits confirmation).

The new format is completely non-compatible with the old one. This means that if you run some existing game with the new engine, and save a game, that save can't be loaded by previous engine.
On the other hand, new engine can still load old saves. Old saves support is temporarily and may be removed in future.
Keep these two points in mind if you plan on upgrading existing game to AGS 3.4.2.

Engine Development / Planning to fix AGS script file paths... again

« on: 16 Feb 2018, 17:02 »

The file access rules - is something that still bothers me in AGS, and I'd really wish to patch it as one of my last ammendments to the engine.

It all started when Radiant asked me to save config file in the user documents instead of current folder, because it does not work when the game is installed in C:/Program Files (or any other non-writeable location). Instead of doing just that I also decided to change how file access works in game scripts too, but I have doubts that did that fully right.
I would like to make final fixes to that, and decided to post here to get any input from other people and make sure I don't screw that up again.

Summing up current state of the file system (as of 3.4.1):
1) When working with file system in scripts (opening files, loading sprites, and so on), following tokens may be used to define location:
* $INSTALLDIR$ - a directory where game was installed.
* $SAVEGAMEDIR$ - a directory for savedgames, one for each system user.
* $APPDATADIR$ - a directory for storing shared data, same for all system users.

2) The rules for working with files are following:
* Absolute paths are forbidden.
* When using $INSTALLDIR$ you cannot write anything, only read existing files.
* Game config lets you set up custom paths for $SAVEGAMEDIR$ and $APPDATADIR$. This is done primarily to let players change save game location according to their preference.
* When no location token is given, engine remaps the path as relative to $APPDATADIR$. Note, that this is different from how it worked before AGS 3.3.5, where path without token meant "relative to game's (installation) directory".
* Now, there is something not very explicit, which was made primarily for backward compatibility: when you are trying to read file using relative path without token, the engine will check two paths: first in $APPDATADIR$, then in $INSTALLDIR$. If a file is found in $APPDATADIR$, then it will be read, otherwise file in $INSTALLDIR$ (if it exists).
The reason for doing this was to silently remap relative paths in scripts in old games to $APPDATADIR$ when they are writing files, but still let them be able to read existing files from the current directory.
But this solution is something I am not very proud of...

The problems, as I see them, are:

1) Is it really good to completely deny writing to the current game directory? Initially I thought it is, since contemporary operating systems have stricter rules to where programs may write files. So this acts as a safety measure to prevent unexperienced game creators from making a mistake (as being said, game may fail if it tries to write to C:/Program Files/...).
On the other hand I myself found at least one case when that may be useful: if you are creating an edit mode inside your game, which creates data for the game itself.
Currently the only way to do that would be to setup custom path for $APPDATADIR$ for the development time and then do not forget to reset it to default before public release.
There is now a token with explicit meaning ($INSTALLDIR$), for which we may have a warning in the manual, telling not to write files there without serious reasons.

2) What should be the way to treat paths without a token? The idea behind changing from treating them as relative of game dir to relative of $APPDATADIR$ is that new users won't make their games impossible to be run from C:/Program Files by mistake. Is it a good reasoning? Because while it may make things safer it also may cause confusion
when user will look for the written files in the game directory and won't find them.

3) Not much related to running new games, but in terms of backward compatibility, is there a better solution for their issue? I am speaking of a situation when the game writes files to game directory, which makes it impossible to be install in particular locations.

The possible solutions I am thinking about right now are:

1) Allow to write files in $INSTALLDIR$. There are options here: make it work always or only if game works in Debug mode, if that makes sense.

2) I don't have a decisive opinion about how to deal with paths without tags.

3) I would like to try implementing different solution for older games. To remind, the problem is this: consider there is a game made a while ago where game author has used paths without token to save files to the game directory. You won't be able to use such game if it's installed somewhere where you cannot write (restricted directories, read-only device). One solution in such case is to simply install it somewhere else. But if that's unwanted or impossible for any reason, may there be a simple fix for this situation?
Right now, as I said, engine silently remaps writing file to $APPDATADIR$, but when reading it has to check both $APPDATADIR$ and $INSTALLDIR$.
Of course this is not ideal, because user may not find files where he expected to. This may be particulary annoying with games which include level editor, like old "ColorWise" game, for instance, where original levels are stored in the game directory, and player will probably expect to find all levels in one place.
So, I was thinking, what if instead of silently changing the path, it would use another option in config. The meaning of option would be "how to treat paths without token", and has possible values corresponding to supported path tokens. Such option could be used like a casual hack: if you've found an old game (or a newer game where author did not consider possible issues) that writes files to the game directory, and that causes trouble for you, you just set this option to something else, like $APPDATADIR$. (Naturally, at same time you may also set custom path for $APPDATADIR$).

BTW, if such option is introduced that may also change the opinion on p. 2), and perhaps paths without tags could mean $INSTALLDIR$ again. Idk about that.

AGS Engine & Editor Releases / AGS 3.4.1 - Patch 1

« on: 28 Jan 2018, 18:49 »

AGS 3.4.1 - Patch 1 released

Current release number: 3.4.1.12

*** Download as installer ***

*** Download as ZIP archive ***

--- NO-MP3 engine variant ---

Linux build package (Editor component) as ZIP archive

AGS source code central repository

Debug symbols database (for analysing crash dumps)

Released: 28th January 2018

Previous stable version: AGS 3.4.0 forum thread

This release is brought to you by:

- Alan v. Drake
- ChamberOfFear
- Crimson Wizard
- Gurok
- monkey0506
- Ryan O'Connor (one bug fix contribution)
- Scorpiorus (improvements to plugin drawing system)

Changes in the Patch 1:

Engine:
- Removed game error reported when GUI coordinates were off the room limits.
- Fixed crash in Direct3D renderer when alt+tabbing out of fullscreen mode.
- Fixed OpenGL fullscreen mode was not minimized when you alt+tab from it.
- Fixed Direct3D and OpenGL renderers unnecessarily applied anti-aliasing on utility sprites (used for transition effects) when "smooth scaled sprites" option was enabled.

What is new in 3.4.1

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.

Script API:
- A new parameter StopMovementStyle is added to following functions: LockView, LockViewAligned, LockViewFrame, LockViewOffset, UnlockView. This parameter can be eStopMoving (default) or eKeepMoving.
- DynamicSprite.CreateFromFile and SaveToFile now support path tokens and comply to the new file path rules (no writing files to the game's installation directory).
- 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, Button.Frame, Button.Loop, Button.View.
- Added GetFontHeight(FontType) and GetFontLineSpacing(FontType) functions.
- Added setter for System.Windowed property, letting to change it at runtime, switching between windowed and fullscreen modes.
- Added System.RenderAtScreenResolution property to change sprite rendering mode at runtime.

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.

Adventure Related Talk & Chat / Survey: what is good in AGS and what needs improvement

« on: 12 Jan 2018, 01:10 »

Hello.

First of all, this is NOT another "feature request" topic.
This is also NOT "what to add to the next version of AGS" topic.

Sorry for this disclaimer. Please read further

.

There are few new engines underway, being made by people known in AGS community, such as XAGE, MonoAGS, and maybe some others we do not know about. They may copy AGS to some degree or reimagine adventure creating tool in their own way. Since I am currently considering contributing to one of them, and just because I think that might be important for any such undertaking, I would like to make a following survey.

The primary targets for this survey are people who have big experience working with AGS, but others may participate too, of course.

Survey has only two simple questions, but they may need extensive answers:
1) What do you like about AGS, and would like to keep if any new creative tool arrives?
2) What do you think should be changed (added, removed, altered)?

Now, this is NOT about simple and obvious things, like
- not being able to change GUI color at runtime, or
- having a limit of N sprites, or
- running on many platforms, etc

but rather about ones, such as
* editing workflow,
* methods to achieve something you want,
* script API design (how well does script allow you to control game behavior), and so forth.

If you have experience working with other game creating systems, and may make a comparison, please do so.

I know that similar discussions were held in the past, but that may be hard to find these posts, so I wanted to make something "centralized" for this time. But links to old forum threads are also accepted.

Adventure Related Talk & Chat / Procedural detective game

« on: 02 Jan 2018, 20:42 »

Hello.

I would like to tell about one idea that interests me. I had it for quite a long time in a form of random thoughts, but recently decided to go and try implementing this even if in a limited form, for starters.

This idea is of procedurically generated detective adventure game.

There was a pretty good number of procedural games in the past, so I guess everyone can imagine what is it in general. I've also seen procedural detective games before. Although I must admit that haven't played much of them, so cannot know many details, but the ones I've seen were mainly based on randomization of predefined roles and scenarios. While that may work perfectly for the game, my intention was to go further (or deeper), and instead of randomly granting every character a role (killer, victim, thief, witness, etc), grant them conflicting personalities and ambitions, that may randomly result in committing a crime under "fortunate" circumstances.

As such this is not only a game project, but also a research project about building a character AI. Or maybe even "story AI".

If you think above is a bit vague, let me give an example.

Imagine there is a mansion full of party guests. Each guest has particular personality traits and wishes assigned at the game's generation. Guests are wandering around the house, following certain rules (like avoiding restricted areas).
Consider one of the guests have a "cleptomaniac" personality, or maybe there is "financial problems" issue troubling them. This character enters a room with some "expensive item" on the showcase. A combination of character's traits and aims gives them a motive to steal the item. They wait for the right moment and do that. This is how the crime takes place.

The peculiarity of this approach that intrigues me much - is that since there are no predefined roles, not only player does not know who the criminal is, but even the game does not "know" that, until crime happened. In fact, there is always a theoretical possibility that more than one crime may take place (with different motives and participants), and maybe even sequences of events following first crime help another one to occur.

As with any AI, it is a matter to programmatically depict decision making. This game would require explaining such things through the code, as the concept of crime itself, clues, motives, ambitions and aims, personality traits and conflicts, and on advanced level - planning a strategy through assuming sequential events, manipulating other people, and so forth.

Obviously such approach also makes it harder to create a flawless scenario, but the challenge is perhaps the interesting part here.
The final goal of this potential project is to create AI that would be flexible and smart enough to generate an interesting game.

Editor Development / The reasons why this project is/was screwed up

« on: 31 Dec 2017, 21:59 »

Following are the reasons why this project was screwed up from the very beginning. Just for the sake of history. I'd like to believe this may help someone to avoid same mistakes, but people seem to rarely learn on their own, so IDK.

Actually, I cannot think of anything that was made right here, from the first steps every mistake that could be made was made.

1. The problem with AGS was the reliance on old library that was already badly working on contemporary systems in 2012. Instead of immediately moving to better up-to-date library (SDL2 or Allegro5), or framework (like ScummVM) the old library was patched to somehow work on wanted platforms.
Usually the patching was performed by a single person. After such person took their leave, little information remained about their work, and whenever any kind of issue arised with the port, it took a lot of effort to figure out what to do.
Often the library was patched having only one particular port in mind. Sometimes a functionality was added right into this patch, different from the rest of the engine, causing inconsistences.

A lot of additional work related to device controls and graphic modes could be omitted, if we could rely on modern library. For example, I had to rewrite graphics renderers 5 or 6 times adding better display mode selection over those years.

The result: AGS is still based on same old library that work worse and worse on contemporary systems.

2. The problem of AGS was that Windows version was glued to particular old version of MSVS, which was even non-free. Instead of immediately looking for a way to remove that dependency, we kept it for several years.

Result: many potential contributors could not contribute because they could not even build it.

3. The problem with AGS was bad program code. Instead of immediately refactor it from top to bottom, this was only partially complete before we switched to compatibility fixes, and then - adding new functionality. Because of that a lot of time was wasted trying to hack new stuff into existing code. Supposedly, the bad code also scared away other potential contributors.

Additional moment: there was already a refactored code made by ScummVM developer, licensed under same license as AGS, which could be used, even if partially. But it was never used.

The result: AGS still has got a lot of non-refactored code which is barely known, and many features or fixes that were very wanted were never added because of that.

4. The problem with AGS was that the engine and editor contained a lot of legacy support that was practically useless for making game in current day, but cluttered up the code and made it difficult to develop it further.

Instead of splitting out legacy support into separate branch, we not only kept it in the engine, but increased its amount by adding support for even older games.
Because of this, adding any new feature required a lot of extra time, necessity to test whether ancient games still run with this engine after every update. This additionally mixed up with the non-refactored code producing more mess.

It may be hard to fully recognize consequences of this decision. A lot of system limits are there only because of legacy support and old plugin API support. There was a time when I spent over half of a year trying to remove these limits while keeping the legacy support, but in the end just threw the code out, so ugly it was.
Similarily, a lot of features could not be easily added simply because there was some fragile legacy stuff that could break.

Result: amount of time just wasted for nothing is impossible to calculate. Neither it is possible to know how much we could have done more if not for this.
Number of potential collaborators probably did not want to participate in project because of confusing code.

5. The problem with AGS was that with very little number of collaborators nevertheless we sometimes wasted time on something that could have been avoided. It was in our interests to take easier routes requiring less job where possible. Instead, the project started with one developer willing to write a class library specifically for AGS instead of using standard one. Another developer kept waiting several months for those classes, purposedly trying to avoid adding standard ones into engine. When it became clear that there will be none, instead of immediately switching to standard library, that second developer, for the reasons he cannot even explain today, decided to follow suggested idea and write these classes himself. In the end he did, kind of, but then realized that with them he will be drawned into maintaining utility classes instead of working on engine itself, so, again, just threw the code away. So, now we do use standard library, but nearly two years were lost.

This is only one such example. I could probably remember other not so useful stuff that I wasted time on, because someone said (in the end many things I did were not even added to the release).

6. The problem with AGS was the lack of automation. Everything had to be made manually. No automatic builds, let alone tests, nothing. If a person wanted to suggest features or changes, developers had to manually build and test their version to just make sure it compiles.
There was no way to know if all ports are still working or were broken by some of the recent additions except for building them all or waiting when someone tries to. And not everyone could build all the ports, naturally.
Making a full release package with all the data - demo game, templates, etc, - became such ordeal, that frankly, I tried to delay release every time until more changes accumulate, simply because I did not want to go through all this too often.

7. The problem with AGS was terrible organization. This was a project without actual leadership nor vision. There was no development plan, no documentation. Everyone just did some stuff as they see fit.
There was very little communication between game developers and AGS developers. With lots of ideas it was difficult to filter out things that were actually important to many people. A lot of critical nuances stayed unknown until occasionally mentioned years later.
A lot of tasks, even mentioned on forums, were never solved, even though several people could state their interest in that. Good example is this thread:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=51340.0
Just look at this:

Add spoiler tag for Hidden:

From 2014 to 2018, and it did not move anywhere. Meanwhile, this is not even related to engine code or C++.

If organization were better, perhaps a number of other problems not directly related to coding engine could have been solved. (e.g. this: http://www.adventuregamestudio.co.uk/forums/index.php?topic=55646.0)
Simply because people could notice that such task exists.

Editor Development / Way to patch the game without replacing it whole

« on: 30 Dec 2017, 15:00 »

This is long overdue, but recently my attention was brought again to this old post from 2014 (I think it is by one of the creators of Primordia):
http://www.rpgcodex.net/forums/index.php?threads/primordia-a-point-and-click-adventure-now-available.49740/page-22#post-3135923

It is nearly 2018 now, but all those issues still exist.

I answered this on gtihub back few years ago, but I guess no one noticed. Perhaps I should've try harder and post here, but, to be honest, don't remember if any game dev has ever asked me about this.

Anyway...

There is this command-line tool pack made by github user rofl0r back in 2012-13: https://github.com/rofl0r/agsutils

Among other things they can unpack and repack AGS game file.
A small caveat - they only known to compile under Linux, so probably might need be updated to compile under Windows too.

The solution to game patching is as following:
1. Provide a patch script and patch contents (e.g. in ZIP archive).
2. Patch script (written in any common scripting language, heck even batch for Windows system) -
2a. unpacks patch archive to folder P.
2b. runs unpacker tool to extract game data to folder G.
2c. copies patch files from P to G.
2d. runs packer tool to recreate game file with the new files of folder G.
2e. deletes temporary files.
3. Profit: you have a game exe with new contents.

EDIT: right, how to create patch in the first place:
a. You need to have two game files: old and new one.
b. Unpack both into folders O and N.
c. Compare the contents and find the files in N that do not match O.
d. Create a ZIP archive that onlu contains changed files.

This may be further improved by writing a simple GUI wrapper over those utilities.

Limitations:
Of course with current AGS package system you won't be able to replace certain items without replacing larger chunk. Sprites is the main problem here, because even inside game package they are stored as another monolithic file (sprcache.dat). Another thing is script modules: they are merged together with main game data (game, character, inventory descriptions, etc). Room files (CRM) have both room background, properties and scripts merged altogether. This is indeed something you cannot change without rewriting way AGS handles these.

Adventure Related Talk & Chat / Integrating AGS with ScummVM?

« on: 25 Dec 2017, 15:43 »

Quote from: morganw on 25 Dec 2017, 15:39

Personally I would like to think there was an opportunity to have a continually developed runtime using the SCUMMVM backend, that does not maintain backwards compatibility and can have a few more contemporary features.

This is one of the possibilities. I had big doubts in the past, particularily because they did not have hardware-accelerated gfx support, which I'd like to have in AGS. But now they seem to have it, or so I heard.

There may actually be two variants here:
- develop AGS runtime as a part of their framework;
- only take their backends system and develop runtime separately (if that's technically and legally possible).

But I guess this all is a separate topic. [Done! –Snarky]

Site & Forum Reports / Google Chrome makes weird warnings about AGS forum links

« on: 24 Dec 2017, 02:16 »

Sorry, that is kind of weird, what started very recently when I click on some forum links in posts leading to old threads (from 2011 - 2012), Google Chrome shows that red danger screen, and sais that -
"www. shuugouteki. net" is a dangerous site that may install malicious software. I have no idea what this site even is, because link clearly is pointing to http://www.adventuregamestudio.co.uk/forums/***.

Going onto these threads step by step from the main forum page works well nevertheless.

What may this be?

AGS Engine & Editor Releases / AGS 3.4.1

« on: 23 Dec 2017, 20:49 »

AGS 3.4.1 released

Current release number: 3.4.1.11

*** Download as installer ***

*** Download as ZIP archive ***

--- NO-MP3 engine variant ---

Linux build package (Editor component) as ZIP archive

AGS source code central repository

Debug symbols database (for analysing crash dumps)

Released: 23th December 2017

Previous stable version: AGS 3.4.0 forum thread

This release is brought to you by:

- Alan v. Drake
- ChamberOfFear
- Crimson Wizard
- Gurok
- monkey0506
- Ryan O'Connor (one bug fix contribution)
- Scorpiorus (improvements to plugin drawing system)

What is new in 3.4.1

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.

Script API:
- A new parameter StopMovementStyle is added to following functions: LockView, LockViewAligned, LockViewFrame, LockViewOffset, UnlockView. This parameter can be eStopMoving (default) or eKeepMoving.
- DynamicSprite.CreateFromFile and SaveToFile now support path tokens and comply to the new file path rules (no writing files to the game's installation directory).
- 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, Button.Frame, Button.Loop, Button.View.
- Added GetFontHeight(FontType) and GetFontLineSpacing(FontType) functions.
- Added setter for System.Windowed property, letting to change it at runtime, switching between windowed and fullscreen modes.
- Added System.RenderAtScreenResolution property to change sprite rendering mode at runtime.

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.

Modules & Plugins / MODULE: Timer 0.9.0 (Alternate variant)

« on: 03 Dec 2017, 23:46 »

DOWNLOAD Timer 0.9.0 MODULE

Latest source code may be found here
Git cloning address: https://ivan-mogilko@bitbucket.org/ivan-mogilko/ags-script-modules.git

Module supports AGS 3.4.0 and higher

Other script modules by me:

Add spoiler tag for Hidden:

Quick pre-word

Few months back I urgently needed a Timer module with certain functionality, and was hoping to download monkey0506's Timer module, but official links were broken (later I found the only working link, but it lead to an old version). So I wrote my own alternate variant, and posted an initial code in the same thread.

I made certain decisions, such as creating a managed class which you have to operate through pointers, that may cause controversy (this clearly has both advantages and disadvantages). Even now I keep having doubts about that. In theory it could be possible to remake it into non-managed class if people will find this not convenient (although there may be complications related to AGS scripting limits).
I also do not know whether monkey0506 had any plans on his own module; I would not mind even merging our modules at some point.

Introduction

The Timer module addresses an issue of built-in timers in AGS: that may be difficult to ensure that you do not reuse same timer for different purpose.

Add spoiler tag for Hidden:

Timer class solves this issue, because you are no longer forced to use same available X timers from the list, but can create any number of Timer variables.

For AGS-related technical reasons there is however a limitation: only finite number of timers may be run at the same time. This number is 20 by default, but may be changed at will.

Add spoiler tag for Hidden:

Timer is implemented as a managed class, which means that you need Timer* pointers to work with it (similar to Character*, DynamicSprite* and so on). This requires certain attention from coder, because pointers may be "null"; on the other hand this lets you to pass Timer object as a function parameter, or return it from a function as return value (something you cannot do with basic structs in AGS).

Timer supports timeout defined in either game ticks or real time. When defining it in real-time you need to keep in mind that the timer's precision depends on FPS (game speed). If your game is running at 40 FPS then the timers are updated only once per 0.025 second (25 ms). In such case setting timeout to, say, 10 ms, won't do much sense (it will still expire after 25 ms).

Timer can be run once (default behavior) or be repeating. Repeating timers will reset themselves after every timeout and never end running. You must remember to stop them yourself when you no longer need them (this is especially important considering that number of running timers is finite).

Timer can be paused and resumed at will. Additionally, you can require all or certain timers to pause and resume with the game (when PauseGame/UnPauseGame is called).

Timers can also be created as local. Local timers remember which room the player was in when they started, and work only while player remains there. If player leaves that room, local timer will stop (default action) or pause. Timers paused this way will resume automatically when the player returns back to their "home" room.

NOTE: From the technical side, it does not matter whether variable is declared in room script or global script, either can be used to make both global and local timers. But remember that if a Timer* variable is in the room script then you won't be able to use it (e.g. stop the timer) and check it for expiration when the player is in another room. Unless that's exactly what you want, better have Timer* variable in the global script.

Since there are three causes for the timer's pause, - script command, autopause with PauseGame and autopause for local timer, - following rule is applied for unpausing the timer: timer only resumes when all three conditions are allowing to. For example, local timer which is configured to automatically pause with the game, will only unpause when in correct room AND game is not paused. If you additionally pause that timer yourself, it will require you resuming it, but resuming the timer in wrong room still won't unpause it until correct room is loaded.

Using Timer

Alright, now to the actual scripting.

Timer pointers are declared simply as:

Code: Adventure Game Studio

Timer *MyTimer;
Timer *tBomb;
Timer *ALotOfTimers[100]; // array of 100 timer pointers
 

These are pointers, but timer objects are not created yet.

Here is how you create and start the new timer:

Code: Adventure Game Studio

MyTimer = Timer.Start(50); // create a timer that runs 50 game ticks
tBomb = Timer.StartRT(10.0); // create a timer that runs 10 seconds (regardless of game speed).
// RT - means "realtime" ;)
// In case you wondered, you can pass value less than second -
MyTimer = Timer.StartRT(0.3); // this timer will run for 0.3 seconds, or 300 milliseconds
 
// Creating repeating timers -
SignalTimer = Timer.Start(40, eRepeat); // this timer will "expire" every 40 ticks and run again
 
// Creating local timers -
RoomTimer = Timer.StartLocal(2000); // this timer will run for 2000 game ticks OR until player leaves the room
ResumingRoomTimer = Timer.StartLocalRT(60.0, eTimerPause); // this timer will run for one minute, but pause if player leaves the room
AnotherLocalTimer = Timer.StartLocal(40, eTimerPause, eRepeat); // repeating local timer
 
// Making the particular timer automatically pause with the game
SignalTimer.PauseWithGame = true; // do this only after you created one, duh
 
// Or maybe you want ALL of the timers in the game to pause when game is paused?
Timer.AllPauseWithGame = true; // better do this once in the game_start()
 

Checking for timer's expiration is done using either of two ways.
First of all you may check timer's property EvtExpired. But because you are using timer pointers, normally you would need to first test if the pointer is not null (unless you are absolutely 100% sure it will always be created at that point):

Code: Adventure Game Studio

if (tBomb != null && tBomb.EvtExpired)
{
    Display("BOOOOM!!!");
}
 

Another method takes into account the pointer fact, and works as a static function which safely manages even null pointers:

Code: Adventure Game Studio

if (Timer.IsExpired(tBomb)) // you may pass even null-pointer there
{
    Display("BOOOOM!!!");
}
 

IMPORTANT: the way EvtExpired works is slightly different from built-in AGS timers.
* In AGS this flag is valid until you check it.
* In Timer module this flag is valid until the next game update. This means that you may check same timer several times, but cannot wait to check it later.

At any point in time you may test if the timer is still existing/active like this:

Code: Adventure Game Studio

if (tBomb != null && tBomb.IsActive)
{
    // bomb is still ticking
}
 
if (tBomb == null || !tBomb.IsActive)
{
    // bomb timer is either did not start yet, or already run out
}
 

Pausing and stopping a timer is done with the other static functions.
(I was considering to add non-static counterparts but did not make them for now)

Code: Adventure Game Studio

Timer.Pause(MyTimer); // pause it
...
Timer.Resume(MyTimer); // resume it
...
Timer.Stop(MyTimer); // stop it completely
// After timer was stopped it is completely useless
MyTimer = null; // you may even nullify pointer now
 

Speaking of deleting a timer, as was said - only running timers number is finite. As with other managed objects, the timer object will be only deleted after all pointers referencing it are nullified You are not obliged to do this, because timer object is small. Also, if you will assign new timer to same pointer, the old object will be safely removed from memory. But if you know that you won't be using same pointer for a while (or no longer in this game), I'd suggest to do that.

Finally, there is a way to get some information about running timer:

Code: Adventure Game Studio

function repeatedly_execute()
{
    if (tBomb != null && tBomb.IsActive)
    {
        Label1.Text = String.Format("Ticks left: %d, seconds left: %.3f", tBomb.RemainingTicks, tBomb.RemainingSeconds);
        if (tBomb.IsPaused)
            Label2.Text = "Bomb is paused";
        else
            Label2.Text = "Bomb is running";
    }
}
 

Possible problems

1. Prematurely clearing or replacing pointer value.

The timer object you have in the pointer variable is the only way to control it. For the technical reasons the module itself also keeps a reference to every running timer. This means that if you nullify your pointer variable (or assign another timer to it) before the previous one has stopped, not only you won't be able to control the previous timer anymore, but the timer is not going to be deleted immediately and keep running.

For one-time timers that may not be a big issue, because they will stop on their own eventually and get deleted by the module's update function. But leaving repeatable timer like that will make it run forever, occupying a slot.

So - always Stop a timer when you no longer need it (unless it has already expired and stopped, that is).

2. Timers in non-state-saving rooms.

AGS has two types of rooms, and non-state saving rooms are special in that they do not keep their data when player leaves. What this means is even the variables are lost.
But as explained above, the Timer is a managed object, and will be kept in memory as long as there is at least one pointer referencing it. And the module itself keeps references to all running timers.

So here comes the possible issue: if you have a Timer* variable in non-state-saving room, and created a timer there, as soon as player leaves the room you will loose control over that timer. If it were repeatable timer, it will also keep running forever, as noted in problem 1).

If you need a timer in non-state-saving room:
* If you want a global timer, make a variable in global script, not room script;
* If you want a local timer that will RESUME when you return to the room, STILL declare a variable in global script. This way you will keep pointer to that timer when return to that room again.
* If instead you want a local timer that stops when player leaves the room, then just create it with eTimerStop parameter as usual, and it will get deleted properly.

Timer API reference

Code: Adventure Game Studio

  // Maximal number of simultaneously running timers (not related to built-in AGS limit).
  #define MAX_RUNNING_TIMERS 20
 
  // Local timer behavior when room has changed
  enum LocalTimerBehavior
  {
    eTimerPause, 
    eTimerStop
  };
 
  // Flags determining the reason for timer's pause (can be combined using bitwise OR)
  #define TIMER_PAUSED_BY_USER 1
  #define TIMER_PAUSED_BY_GAME 2
  #define TIMER_PAUSED_BY_ROOM 4
 
 
  //
  // General operations.
  //
  
  /// Start the timer, giving timeout in game ticks.
  static Timer *Timer.Start(int timeout, RepeatStyle repeat = eOnce);
  /// Start the timer, giving timeout in real time (seconds).
  /// Remember that timer can be only as precise as your GameSpeed (40 checks per
  /// second, or 0.025s by default).
  static Timer *Timer.StartRT(float timeout_s, RepeatStyle repeat = eOnce);
  /// Starts local timer working in game ticks, that may be paused when player leaves the room
  static Timer *Timer.StartLocal(int timeout, LocalTimerBehavior on_leave = eTimerStop, RepeatStyle repeat = eOnce);
  /// Starts local timer working in real time (seconds), that may be paused when player leaves the room
  static Timer *Timer.StartLocalRT(float timeout_s, LocalTimerBehavior on_leave = eTimerStop, RepeatStyle repeat = eOnce);
  
  /// Tells whether timer has JUST expired. Safe to pass null-pointer.
  static bool   Timer.IsExpired(Timer *t);
  /// Stops the running timer. Safe to pass null-pointer.
  static void   Timer.Stop(Timer *t);
  /// Pause the running timer. Safe to pass null-pointer.
  static void   Timer.Pause(Timer *t);
  /// Resume the running timer. Safe to pass null-pointer.
  static void   Timer.Resume(Timer *t);
  
  //
  // Additional setup.
  //
  
  /// Gets/sets whether all timers should pause when game is paused
  static bool  Timer.AllPauseWithGame;
  /// Gets/sets whether this particular timer should pause when game is paused
  bool Timer.PauseWithGame;
  
  //
  // Current state inspection.
  //
  
  /// Tells whether timer is currently active (counting down).
  readonly bool  Timer.IsActive;
  /// Signal property telling that the timer has expired. This flag will remain set
  /// for one game tick only and self-reset afterwards.
  readonly bool  Timer.EvtExpired;
 
  /// Gets the home room of the local timer (returns -1 if timer is global)
  readonly int  Timer.HomeRoom;
  /// Gets what this timer should do when home room gets unloaded
  readonly LocalTimerBehavior Timer.WhenLeavingRoom;
  
  /// Gets whether this timer is working in real-time
  readonly bool  Timer.IsRealtime;
  /// Gets the timer's timeout in game ticks
  readonly int   Timer.TimeoutTicks;
  /// Gets the timer's timeout in real-time (considering current game speed)
  readonly float Timer.TimeoutSeconds;
  /// Gets the remaining time in current game ticks
  readonly int   Timer.RemainingTicks;
  /// Gets the remaining time in real-time (considering current game speed)
  readonly float Timer.RemainingSeconds;
  /// Gets current timer's paused state (0 - working, >= 1 - suspended)
  readonly int   Timer.IsPaused;
 

Completed Game Announcements / Last & Furious (MAGS Nov 2017 entry)

« on: 01 Dec 2017, 17:38 »

Crimson Wizard and Jim Reed present:
(made for MAGS Novemeber 2017)

Last & Furious

Download links:
Dropbox: https://www.dropbox.com/s/0u7opdaxku1459c/Last%27n%27Furious.zip?dl=0
Mediafire: http://www.mediafire.com/file/wq8xgjbfyvalq40/Last%27n%27Furious.zip

Project source licensed under Creative Commons: By Attribution 4.0 (except music, which has its own authors and licenses)
Download: https://www.dropbox.com/s/xsd49x9i6f7svsg/Last%27n%27Furious-Source.zip?dl=0

Screenshots:

Description:
'Last & Furious' is a top-down racing game, featuring single track, two physics modes, wonky collision system and hastily set up opponent AI.

Controls: arrow keys.
Car behavior: can thrust forward, steer and brake (no backpedal, sorry).
Physics setup: when starting new race choose between "Safe" and "Wild" physics mode (they will give you two different experiences!). It is also possible to disable car-vs-car collisions (they still collide with the walls though).

Physics model in this game is actually configurable. If you feel adventurous, go to "Data" subdirectory. There you will find "race_safe.ini" and "race_wild.ini" files which contain parameters for related game modes.

Credits:
Code: Crimson Wizard;
Art: Jim Reed (was also generating tech ideas);
Music: "Car Theft 101" by Eric Matyas (www.soundimage.org), "Welcome to the Show" by Kevin MacLeod (incompetech.com).

Game DB page: http://www.adventuregamestudio.co.uk/site/games/game/2216/

Advanced Technical Forum / Dynamic sprite issue: when assigning sprite may not update character looks

« on: 24 Nov 2017, 22:07 »

Well, damn, looks like I just run into one of those obscure AGS bugs. Took me several hours to, first, realize that could not be a mistake in my script, and then find out why is it happening exactly, staring into the engine code.

Following example is based on default game template.
Room 1 script:

Code: Adventure Game Studio

// room script file
 
DynamicSprite *Sprite;
 
function room_Load()
{
  Sprite = DynamicSprite.CreateFromExistingSprite(2000);
  ViewFrame *f = Game.GetViewFrame(player.View, 0, 0);
  f.Graphic = Sprite.Graphic;
}
 
function on_key_press(eKeyCode key)
{
  // These lines cause the bug ======
  //if (Sprite != null)
  //Sprite.Delete();
  // ================================
  
  DynamicSprite *new_sprite = DynamicSprite.CreateFromExistingSprite(2000 + Random(9));
  Sprite = new_sprite;
  ViewFrame *f = Game.GetViewFrame(player.View, 0, 0);
  f.Graphic = Sprite.Graphic;
}
 

So, this code is very simple. What it does:
- It takes certain View frame, and replaces original sprite with dynamic sprite, which in turn is a copy of some character sprite.
- On every key press it creates NEW dynamic sprite from the random range of character sprites, and puts it to same View frame.
Don't bother wondering why would I need such script, that's just an example of certain actions.

Run the game and hold any key (e.g. space bar). Character's image will beging to cycle randomly.

Now, the interesting part. See these commented lines where the previous sprite gets explicitly DELETED before assigning new sprite to the same pointer? Thinking logically, that should be right thing to do, and should be safe to assume that nothing bad is going to happen?

Well, uncomment these lines:

Code: Adventure Game Studio

if (Sprite != null)
    Sprite.Delete();
 

and run the game again. Hold space bar, and... you see that character's looks do not change anymore.
HOWEVER, if you walk a little and then make Roger take original direction, you will see, that the frame 0 sprite actually is different. So it DOES change after all, it's just that AGS did not redraw it in time.

So, why is this happening, and how can DynamicSprite.Delete make any difference?

AGS has character cache, where it stores last character's image with additional effects (tint, lighting, area zoom) applied. On every update it checkes whether anything has changed and if not - it keeps cached sprite.
When you create NEW dynamic sprite, and assign it to the view frame, the number of sprite is now different from old one, so AGS knows that it needs to reset cache.

But when you delete an old sprite FIRST, its SLOT number frees, and the next dynamic sprite gets created on the SAME SLOT, having same index as the old one has had! And AGS cannot detect that the change happened!

To prove this point, change the code:

Code: Adventure Game Studio

function on_key_press(eKeyCode key)
{
  // Temporarily keep an old sprite in another pointer
  DynamicSprite *old_sprite = Sprite;
  
  DynamicSprite *new_sprite = DynamicSprite.CreateFromExistingSprite(2000 + Random(9));
  Sprite = new_sprite;
  ViewFrame *f = Game.GetViewFrame(player.View, player.Loop, player.Frame);
  f.Graphic = Sprite.Graphic;
  
  // Now delete the old sprite by referencing the temp pointer
  if (old_sprite != null)
    old_sprite.Delete();
}
 

If you run this code and hold space bar, the character will be animating again.

Now, the above is just a dummy script example. If you have a more complicated script, with multitude of dynamic sprites, where you cannot reliably keep track of when the old slots are freed (or rather do not want to do that), for that case I found another workaround to force AGS reset character cache:

Code: Adventure Game Studio

DrawingSurface *ds = Sprite.GetDrawingSurface();
ds.DrawPixel(-1, -1);
ds.Release();
 

Thing is that when DrawinSurface.Release is called, it checks all (supposedly) places where this sprite could be used, and releases all related caches. But some drawing operations MUST be complete to make it do so! Hence we just draw one pixel outside of the sprite. While sprite physically stays unchanged, DrawingSurface object registers modification.

Now this will work too:

Code: Adventure Game Studio

function on_key_press(eKeyCode key)
{
  if (Sprite != null)
    Sprite.Delete();
  
  DynamicSprite *new_sprite = DynamicSprite.CreateFromExistingSprite(2000 + Random(9));
  Sprite = new_sprite;
  ViewFrame *f = Game.GetViewFrame(player.View, player.Loop, player.Frame);
  f.Graphic = Sprite.Graphic;
  
  // Poke AGS to make it reset sprite cache
  DrawingSurface *ds = Sprite.GetDrawingSurface();
  ds.DrawPixel(-1, -1);
  ds.Release();
}
 

PS.
The actual reason for this bug is that when DynamicSprite gets deleted, it does not clears related CHARACTER caches. Which is very strange, because it clears GUIs and Room object caches. This makes me think that there could be a simple oversight.

PPS.
Also, that bothers me, but I have a suspicion that if you don't call DynamicSprite.Delete, but simply overwrite pointer with new sprite, the actual bitmap does not get deleted and stays in system memory (aka "memory leak"). This is explicitly coded so in AGS engine, and I cannot understand why. This might require a separate research.

Recruitment / [HELP FOUND] Artist for a small MAGS project

« on: 03 Nov 2017, 22:39 »

Hello

.

I decided to try making a game for November MAGS, and for that I am looking for a 2D artist.

This is going to be non-adventure, arcade sports (kind of) game, which requires top-down view sprites and backgrounds, featuring simplified (may be tiled) contemporary landscape and objects (vehicles, people, etc).

Game resolution is not set, since it mainly depends on art it may be anything you can handle. I'd prefer to have at least 640x400 if possible, but that's not critical.

Personally, I am going to script the thing, but will be open for any good ideas and suggestions on game design.

I have to frankly admit that sometimes get busy with urgent tasks in my life, but even if we won't make it to the MAGS deadline, I will be willing to release this game anyway.

Please PM me if you are interested, and I will tell you more details about the game.

UPD: I found someone, thanks to everyone who PMed me

Engine Development / Debugging AGS engine in MSVS 2015

« on: 14 Oct 2017, 18:25 »

I always had this issue when debugging AGS engine in Visual Studio before: when you break the program execution (e.g. by placing a breakpoint in the code) there was always a delay of few seconds before VS begins to respond to mouse and keyboard input, like if something is locking the input. It was happening only once per debug session, when you break the program for the first time. I had a suspicion that it has to do something with how Allegro 4 works, but could never find anything related in the internet. That was mildly annoying, and in the abscence of solution I decided to just live with it.

Now when we switched to MSVS 2015 in the master branch, this issue became much worse. This input freezing does not go away. It looks like this: program stops at breakpoint, and everything seems to be okay: no extra CPU load, the cursor is flickering in the VS as normal, but as soon as I touch the mouse or press any key, everything freezes for several seconds. This repeats every time after any signal from input device. If I move mouse too much at once I have to sit and wait for a minute before I can even shutdown debugging session forcefully.

Apparently it affects whole system, not just MSVS, because switching to other program windows does not help.
I only found one possible workaround: if I start or continue debugging, then switch to another application quickly, before next breakpoint is hit, everything works normally. But doing this trick really wastes my time alot, besides it's a game of chance.

So, right now I am almost unable to debug the code in the master branch using MSVS debugger.

What confuses me also is that since we changed to MSVS2015 there had to be other people who also tried building and running the engine. Have anyone else noticed similar thing, or it's just me?

I remember finding some kind of solution in the web a long while ago, something about hacking a registry, and IIRC that kinda worked (although not 100%), but seems bit unreliable to me, also unfortunately I forgot what it was and how to search for it.

NOTE: this does NOT occur when debugging Editor, even if I put breakpoints in C++ native code.

EDIT2: After further testing I can confirm, a call to Allegro's function install_mouse causes mouse issues in the debugger, call to install_keyboard locks up keyboard input inside MSVS correspondingly.

EDIT3: Finally was able to find the threads on Allegro forums, confirming and explaining this issue:
https://www.allegro.cc/forums/thread/615043
https://www.allegro.cc/forums/thread/615012/1009606#target

Quote

Allegro grabs the system keyboard and mouse. So when the game crashes or reaches a breakpoint, the IDE pops up, but all mouse movements and keyboard events have a several seconds lag because the allegro handlers simply do not answer. Mouse buttons do not work at all. Imagine to single step like that.

UPD4:
Another couple of descriptions of the similar problem. I am not completely sure if the cause is same, but description of the symptoms match:
http://the-witness.net/news/2012/12/finding-and-fixing-a-five-second-stall/
https://stackoverflow.com/questions/9727327/windows-keyboard-hook-hangs-debugger

Pages: [1] 2 3 ... 11