Topics

I am implementing a Seek function for the File class in AGS script, and would like to know opinion on its parameters.
Should it follow the C fseek standart in the sense of declaration?

Code: ags

enum StreamSeek
{
   eSeekBegin,
   eSeekCurrent,
   eSeekEnd
};

managed struct File
{
...
    import bool Seek(int offset, StreamSeek whence = eSeekCurrent);

    readonly import attribute int Position;
...
}

Is the function protoype (return value, order of arguments) is good, and is the default value convenient?

[E:]

I need an advice...

I found I mistakenly removed one feature from AGS, the "Letterboxed mode"; I thought it is merely related to how game selects graphics mode. In fact it appears it is used for game appearance design, forcing letterboxed mode. I need to restore this for AGS 3.3.0, but here is one concern that confuses me.

Basically, it can be said that it increases the vertical size of the game when setting display up.
If the game is 320x200, the AGS will set it up as if it were 320x240, and if the game is 640x400, the AGS will set it up as if it were 640x480.

In this mode the borders are visible even if game is run windowed, proving they are part of game design, rather than result of graphics mode.

In the past AGS was restricted to very limited possible graphics modes. For example, 320x200 game could run only either 320x200 or 320x240 (plus integer scaling). This means that letterboxed-by-design game could be run only as 320x240. This practically ensured the borders always stay same size (40 for letterboxed 320x200, 80 for letterboxed 640x400).



Now, the AGS 3.3.0 update1 improved the resolution selection, making more variants available. And upcoming free resolutions update will make it even better with any combination of window resolution / game frame position. And this raises a question: how should the letterboxed-by-design game be dealt in such cases?

It is probably valid that such games should be treated as having higher vertical size. But what if the player's monitor does not support square ratio and the game will require additional borders? This means that the total amount of "blackness" around game will increase, making things look worse.
Does it matter? If not, how this should be solved?


Additionally, with Custom (game) Resolutions, shouldn't this letterboxed mode be valid for other resolutions? Should these be only 16:10 and 16:9 resolutions?
Or maybe this may be worth to introduce some kind of "game borders" project setting and let developer choose any random borders height and width?


E: Of course, I could leave this as it is for the time being (besides it does not look like a lot of people use this), but I am interested in having some plan for the future.

Alright, this is extremely stupid, but I found myself in a big confusion... again.

I needed some utility classes to continue work on AGS features (like custom resolutions and limits), - primarily hashmap, - so I wrote ones. But now, when I was about to push them, I started to wonder if I am doing a right thing rewriting what already exists. Does anyone remember why we decided not to use STL in AGS? Or did we? I think I've lost a track of reasoning there. When we started all this there was a talk about writing our own utility classes. Monkey wanted to do this, but after few months he told he can't. So I decided to do this instead, but wasn't that some kind of inertia, not rational thinking?

Indeed Hash Map is only included in C++11 library (as unordered_map), therefore we would need to move to C++11. This means we need to reorganize the way AGS is built. For instance, get rid of pre-built Allegro libraries for Windows and make everyone build them on their own from source code.
This will take some time... meaning other work will be delayed.

This all is extremely stupid, but I do not feel apt to decide such things. This all gets real results further and further, and I keep wondering if I'll ever finish what I started. I feel like I am rethinking same things over and over again, without being able to get to conclusion.
Meanwhile there was talk about writing a "new AGS" by other people. I don't know, have they started? Maybe what I do will become irrelevant after a short while?


It bugs me that I could do alot more if I weren't so unsure of what is right way to do.

I was surprised to know that there's a newer online manual: http://www.adventuregamestudio.co.uk/manual/ linked from AGS homepage.
When it was created? I might have missed that.

I always find it easier to use the one in Wiki (accessible to forums): http://www.adventuregamestudio.co.uk/wiki/Contents_(manual)
But it's outdated (version 3.1).

Is there a plan to make Wiki refer to the "real" manual?
Also, how it is created and who is responsible for updating it? Perhaps there's a sense to update it to 3.3.0.

Recently Gurok brought attention to inconsistence in how properties are arranged inside groups in the editor.

For example, "Visible" property is in "Appearance" group for GUI, but in "Design" group for room object.
Similarly, I can tell that "Clickable" property is in "Appearance" for GUI for some reason (room object has it in "Design" too).
May be there are other cases.
Perhaps someone could make a simple "standard" for property groups? After that all inconsistencies could be fixed accordingly.

Is it possible to move issues between project trackers?
If yes, may this issue be moved to Editor project? http://www.adventuregamestudio.co.uk/forums/index.php?issue=545.0

[Please, do not use this for your actual game release yet]

First of all, I apologize for closing previous thread with this name (I asked mods to delete it). I've had numerous issues with the first version of this build and got very upset, thinking that I won't be able to deal with all the hacks in AGS code related to letterboxing.

After some time I saw that probably it is possible to fix them. So, I am reposting the improved version of the build.

//---------------------------------------------------------------------

This is a test build with improved display resolution setting, based on latest 3.3.0.
This version is some kind of "intermediate" between 3.2.1 and custom resolutions. It features a relatively free window resolution. Since everything related to graphics is pretty fragile in AGS, and this is supposed to be an update over current release, rather than completely new version, I tried to keep changes to minimum.
Yes, I moved from "hotfix" idea to "update", because this is really can't be viewed as a hotfix anymore.

http://www.mediafire.com/download/rdzu8zaacmt2065/ags_3.3.0_scaling_update.7z

Git branch: https://github.com/ivan-mogilko/ags-refactoring/tree/update_scaling

This includes only acwin.exe to replace the one in 3.3.0 installation.

Now in master branch:
http://www.mediafire.com/download/5a67mvl0d63i416/AGS-3.3.0.zip

Please, do not use this for your actual game release yet. It must be tested first.
I ask anyone who has little time to test if that works for any game resolution / display resolution combinations.

What it does (in theory):
1. It should support running game at almost any resolution, provided that a) the resolution is not smaller than scaled up game, and b) its sizes are multiplies of scaling multiplier.
For example, if game scaling is 4, then window sizes should be multiplies of 4. If scaling is 3, window sizes should be multiple of 3, etc.
This restriction is implied by how black borders (letterboxing/sideborders) work in original AGS.
If scaling is 1 (no filter), window can have any size (I think).
2. It should automatically find maximal supported nearest-neighbour scaling, if the requested scaling failed. In any case it searches for all combinations of sideborders/letterbox (depending on setup options). Therefore if you computer supports just any resolution equal or larger to game size, AGS must find and use one. Resolutions with desktop aspect ratio are given higher priority.
3. Writes bit more interesting stuff to the log.

What it does not:
1. It does not allow absolutely free window size selection.
2. It does not allow non-integer scaling.
3. It does not allow downscaling.
4. It does not allow to explicitly choose position of the game inside window (proportional, stretched, centered, etc) - this is defined only automatically.
5. This has nothing to do with custom game resolutions.

//---------------------------------------------------------------------

Known issues:
1. Resolution selection now works differently, and you may sometimes get surprised by results; for example, you may get a small "boxed" game inside a larger fullscreen without expectation. Well, this is not really a bug, yet needs to be checked, to know if people are generally ok with that.
This is "cured" by disabling sideborders and removing "force letterbox" check in winsetup.
2. This is rather related to old AGS logic, but if "Force letterbox" is not checked, engine always looks for non-letterboxed resolution first, and the game may end up stretched to fullscreen, breaking aspect ratio, even though there may be more correct resolution available.
3. Proper letterboxing is disabled in winsetup for 800x600 and 1024x768 now, I need to fix this; but it should generally work: you may put "forceletterbox=1" into setup file.
4. Sometimes the part of cursor may be drawn above borders.


What needs to be tested:
1. All game resolutions / scaling combos.
2. Room transitions, especially fade-in/fade-out.
3. Scrolling rooms.
4. Built-in dialogs (default quit/load/save dialogs).

I was looking into how WFN font works lately, and it appears that SCI font has very similar format. WFN is like SCI just with data saved in different order. It will take close to no time to add SCI fonts support to AGS, so that they could be used without preliminary conversion. Engine and editor will bring them both to same internal type on load, so there will be zero difference in how they work.
May this be useful?
What could have been CJ's reason not to do this and use WFN instead? Could that be legal issues?

I didn't pay attention before, but "Go to line" command selects whole line in the script editor. I never saw such behavior in any text editor I used. Is this a right thing to do? If user occasionally presses a key after the command, he/she will delete the line of code.

Frankly I am not quite in the mood to talk much about this, but I know that I should explain something, so, I'll try to put this as simple as possible.
Regardless of how much I try to persuade myself and force further, I feel that I am unrecoverably loosing faith in both the project and my own abilities. Looking back, I made so much mistakes, mostly in organization and design of the changes I did; I lost too much time pursuing several goals simultaneosuly; the plan I made up when just started to refactor the engine was put aside in favor of the new features. I think I was in some dire need to do something captivating back in mid 2012 when I started working, and that played a negative role, I was too hasty, jumping from one thing to another. My mistakes depress me so much that I start to feel repulsion thinking about this work.
As I learnt the existing code better and about problems that were required to be fixed, I was coming to the thought that AGS is simply not suited for upgrade that everyone wanted. It appears to me that although it reached certain state with existing features and capabilities, it took more than 10 years to evolve into what you have now with the work of one man (Chris Jones), and it will take too much time to evolve further to the next "level" to keep up with the demands of the modern day game developers and game players.
Perhaps it could be better to start a new engine, back couple of years ago, built with completely different design in mind, to replace AGS, but it's too late for me to try that now, especially not alone, especially while other engines and frameworks appear - this makes me feel that my work is getting useless in the perspective.
I was thinking about maybe making couple of more versions before stop, but I feel emotionally exhausted now. I guess I am simply not the guy to take on a lead in something (nor I really wanted to, it just happened... somehow).
Honestly, I am pretty much ashamed to tell all this, but I think I should tell the truth.

This issue must be pretty important for both game devs and players, but somehow evaded my attention so far, maybe because I download games not much and not often. Problem is that AGS Editor itself does not let create patches for the game, only compile full game, therefore fixed version may be as large as a previous version.

I want to ask, have anyone tried using binary patching? For example, I found this:
http://www.daemonology.net/bsdiff/
It has Windows version too (http://sites.inka.de/tesla/others.html#bsdiff).

Maybe someone knows other similar programs?

[hotfix 1]

AGS 3.3.0 released

*** Download as installer ***

*** Download as ZIP archive ***

--- NO-MP3 engine variant ---

AGS source code central repository

Debug symbols database (for analysing crash dumps)

Please, read "Upgrading to AGS 3.3" topic in the manual that comes with this version before upgrading your game project to 3.3.0! It contains important information on few potential problems you may encounter.

Latest update: 29th July 2014

(includes hotfix 1 to the game compilation that could break if you moved item folders in project tree)

(includes hotfix 2 which fixes couple of minor bugs)

(includes update 1 with properly working letterbox and pillarbox graphic modes, the ones with side & top/bottom borders)

(includes hotfix 3 which fixes few more rare bugs, introduced between first 3.3.0 and update1)

Backup of the previous version (hotfix 2):

Spoiler

Installer: http://www.adventuregamestudio.co.uk/finals/AGS-3.3.0-hotfix2.exe
ZIP-archive: http://www.adventuregamestudio.co.uk/finals/AGS-3.3.0-hotfix2.zip
No-MP3 engine: http://www.adventuregamestudio.co.uk/finals/AGS-3.3.0-hotfix2-noMP3.zip

[close]

This version is a product of collaborative work of the following people (who worked and contributed in different time, but whose work was used either directly or as a reference to make this release):

Spoiler

  Bernhard Rosenkraenzer
  Cristian Morales Vega
  Francesco Ariis
  Gilad Shaham
  Ivan Mogilko
  Janet Gilbert
  Jochen Schleu
  Michael Rittenhouse
  Paul Wilkinson
  Piotr Wieczorek
  rofl0r
  Scott Baker
  Shawn R. Walker
  Steve McCrea
  Steven Poulton
  Sunit Das
  Tobias Hansen
  Tom Vandepoele
  Tzach Shabtay

[close]

...and of course Chris Jones, original creator of AGS .

For information on upgrading your game project to 3.3.0 please check "Upgrading to AGS 3.3" topic in the manual.

Changes since version 3.2.1:

* Editor UI now features docking panels. See video demonstration on how to use them.
* Project tree now features folders for characters, dialogs, inventory items, guis, rooms, scripts and views.  The "Sort room by number" menu command now sorts rooms within folders.
* In project tree respective script body and header files are now grouped under one item.
* Project tree now supports drag & drop operations to move items. "Move up/down" commands are removed from context menu.
* Added a "Find all usages" context menu item to find all usages for characters, dialogs, views, inventory items and global variables in script. NOTE: this only searches for script name, not numeric ID.
* Added a "Navigate (in tree)" context menu item for almost all document tabs, which navigates to their node on the project tree.
* In script editor, pressing Ctrl+G will now open the "Goto line" dialog. The shortcut to open global script has changed to Ctrl+Shift+G (and shortcut to open the global header - to Ctrl+Shift+H for consistency).
* Added a "Replace sprite(s) from source" context menu command in Sprite Manager.
* Added a "Browse" button to the "Create in folder" field in the Start New Game wizard.
* Sprite Import window is now resizable.
* Improved how autocomplete list in script refreshes its contents.
* Editor no longer allows to create more game items than engine supports (fonts, cursors, dialogs and inventory items), which could result in crashes in Editor or running game.
* Fixed incorrect selection of a new sprite, imported while the "Select sprite" dialog is open.
* Fixed sprite lookup in folders, differing only by name case.
* Fixed the script editor sometimes mistakenly notified that script was changed externally after it was saved in the editor.
* Fixed overlapping labels in the Editor Preferences dialog.

* Increased maximal Font number from 15 to 30.
* Implemented proper alpha blender for blending two 32-bit sprites with alpha channels. Added new option for gui alpha blending which turns the proper blender on. For the general cases (such as DrawingSurface.DrawImage function) a new setting is added in "Visual" group, named "Sprite alpha rendering style".
* Added "DialogOptionsRenderingInfo.HasAlphaChannel" property that lets you enable alpha channel for custom dialog option surface.
* The "Old-style game-wide speech animation speed" game setting in "Backwards compatibility" group is replaced with two settings in "Dialog" group: "Use game-wide speech animation delay" (switch) and "Game-wide speech animation delay" (value).
* Added "Translated" property to ListBox gui control, which forces engine to translate ListBox items.
* Added "Dialog.SetHasOptionBeenChosen" function which lets you to set or reset "option been chosen" flag.
* Added eKeyNone constant which lets you to set "no/undefined key" (whenever eKeyCode type is required).
* Added SkipSpeechStyle enum to define speech skipping mode instead of using bare numbers.
* Added two more options for the speech skip style: "skip by key only" and "skip by mouse only" (no timer).
* Added new Speech class which groups several speech-related properties.
This renders some of the previously existing variables and functions obsolete:

Spoiler

Deprecated function/variable	New property
SetVoiceMode	Speech.VoiceMode
SetSkipSpeech	Speech.SkipStyle
SetSpeechStyle	Speech.Style
game.close_mouth_end_speech_time	Speech.AnimationStopTimeMargin
game.speech_text_align	Speech.TextAlignment
game.skip_speech_specific_key	Speech.SkipKey
game.talkanim_speed	Speech.GlobalSpeechAnimationDelay

[close]

* Added Speech.CustomPortraitPlacement, Speech.PortraitXOffset and Speech.PortraitY properties which let you to customize the position of speech portraits on screen.
* Added Speech.DisplayPostTimeMs property that makes speech portraits and/or text stay on screen some more time after speech was finished playing.
* Added Speech.UseGlobalSpeechAnimationDelay and Speech.GlobalSpeechAnimationDelay properties that let you to dynamically enforce and alter game-wide speech animation speed.
* SetMusicMasterVolume legacy script function now accepts volume values between -210 and 100 (was between 0 and 100). This may be used as a workaround for guaranteed music mute if using old audio system.
* Fixed "savegameindex[]" array was declared with incorrect size in script (20, while it must be 50).

* Engine can now load and run old games made with AGS 2.5 and higher (the level of compatibility may vary).
* Enhanced winsetup by moving many options under "Advanced" section and removing "Replay" option which was not usable for years.
* Reimplemented alternate display modes, now side-borders and top/bottom borders should work properly for all game resolutions.
* Added x5, x6, x7 and x8 scaling filters, as well as "Max nearest-neighbour filter" option in setup which automatically finds maximal supported scaling filter for your screen.
* The game automatically fallbacks to Software graphics driver if the Hardware one could not run or initialize gfx mode for any reason.
* Windows version of the engine will now write crash dump on "out of memory error" to help diagnose the situation if this occured due bug in the engine.
* Improved character walking animation at 60%-80% scaling.
* Game.ChangeTranslation() script function no longer causes game to quit if the translation file belongs to different game or has unknown format.
* Fixed inventory items and cursor crosshair with alpha channel not being drawn properly.
* Fixed side-borders that were not applied properly at newer (larger) widescreen resolutions.
* Fixed crash that occured when ListBox.GetItemAtLocation() is called from repeatedly_execute_always() just before the list box is about to be drawn on screen for the first time.
* Fixed custom dialog options clickable area by correcting its horizontal coordinate range.
* Fixed error which took place when user restored a game saved with background music playing, in case the music is not found in resources anymore.
* Fixed audio behavior during cutscenes (error caused audio volume to reset to default). Also AudioChannel.Volume will now return correct value when called from skipped cutscene.
* Stopped play.close_mouth_end_speech_time variable from making effect in voice mode and Sierra-style speech (which it wasn't supposed to do).
* Fixed return value of the AudioChannel.PositionMs for MOD/XM clips;
* Fixed division by zero which occured if there was a 1px tall walkable area (a precisely straight horizontal line) with vector scaling applied.
* Fixed OGG speech ending prematurely if the audio file size is a multiple of 32 KB.
* Fixed bug that could let user to load corrupted savedgame, which in turn could cause more trouble.


Some optional engine features:

* Log output. Enabled either in setup file, by putting "log=1" line under "[misc]" category, or "--log" parameter if running from command line; also "--no-log" command line parameter overrides setup file and disables logging.
Log file is called "ags.log" and it is saved in "Users\<Name>\Saved Games\.ags" on Vista, Win7 and Win8, and in "Documents and Settings\<Username>\My Documents\My Saved Games\.ags" on WinXP.
Other platforms have their respected paths, e.g. Linux will write to "$HOME/.ags".
* Threaded audio support. This feature has both pros and drawbacks, and is not currently recommended to be used for your project on desktop platforms by default and without testing. You may enable it in setup file by manually adding a "threaded=1" line under "sound" section.
* Added three "overriding" options for setup file:

Code: text

[override]
multitasking=0/1
os=dos/win/linux/mac
upscale=0/1

Multitasking - overrides game's multitasking mode. Useful if game has lengthy unskippable sequences. Keep in mind that this will lock game in the given mode and make it ignore script commands that change it.
Os - overrides System.OperatingSystem return value. Useful for ports when game disables some feature for the system because it thinks it's not supported.
Upscale - lets to run lo-res (320x200/240) games in "hi-res" mode (640x400/480). May be useful for running old pre-3.1.0 games with new interpreter.
* For every "long" command line argument the traditional GNU form (--arg) is supported, for example "--windowed", "--letterbox", etc.


* Additions to Editor Plugin API:

* Added property for getting playable character.
* Added property for getting ScriptsAndHeaders collection.
* Added methods for refreshing project's tree.
* Added method for refreshing property grid.
* Added methods for controlling output panel.

[Foreword]

//===========================================

Foreword

The branching model for AGS is defined considering the specifics of its development.
The development roughly breaks into following tasks:
1. Developing the Editor
2. Developing the Engine (interpreter) core functionality
3. Developing the Engine ports

The game features provided for creating and editing by the Editor should correspond to the feature support by the Engine. However, particular changes may be strictly related to only one of those programs.
The engine ports sometimes require their own improvements. Compatibility fixes providing support for running older games are usually made in sake of ports, but the changes occur in the Engine's core.

Branches.

Generally we base the branching model on a following reference:
http://nvie.com/posts/a-successful-git-branching-model/
It seems easy to follow and helps to keep most stable code in the primarily accessed branch, therefore the users who prefer making builds themselves will get the last fixed stable version without searching for proper branch.

On top of this model we add one exception for hotfixes and minor compatibility fixes: we allow them to be applied to master branch directly, and also we allow not to increase the release version after every single immediate bugfix and compatibility fix.
This makes it generally simplier to add ones; and it is still possible for bug reporters to mention the precise program state they used by refering to commit they were at when making the build (by commit hash).
This exception may be removed later should the development process become more complex or should such exception cause troubles.

Branch summary

In summary, the branching rules are following:
master - is a stable branch, which receives merges from "release" and "hotfix" branches when the code is good enough. There are tags, that mark version releases. Changes should not be made directly to "master", with previously mentioned exception of immediate bug fixes and very simple compatibility fixes.
Only "hotfix" and "release" branches could be merged in. This branch is meant for common end-users, who want be sure they are always using "official" stable version.

hotfix - these branches are used when the serious bugs are found in recently made release, that is when the new released code is already in "master". After making commits and testing them, the contents of a branch are merged to "master".

release - auxiliary branches for the final preparations before new version release. It is forked from "develop" branch when it is clear no more features are to be added to the nearest upcoming version. Only bugfixes are allowed. When it is done, it is merged to "master".

develop - main development branch. All new things are done here. When approaching new release, the "release" branch is spawned from "develop". From that moment all fixes to the closest release are done in related branch, and "develop" is used to start working on the next release.

feature - feature branches are temporary auxiliary branches. They are forked from any other branch (presumably from "master" or "develop") by a team or individual developers, to work separately on certain feature. It is strongly recommended to create "feature" branches in personal repositories, rather than in central one, unless it requires attention of multiple developers over a long period of time. The feature may target next upcoming release, or some distant release in future. When finished, it is merged to "develop".


Branch naming

The "master" and "develop" branches always keep their respective names. Other branches are named with regard to the title of version or feature they are dedicated for.
Hotfix branch should be named "hotfix-X.X.X.Z", where X.X.X is the last release version and Z is a new planned build number.
Release branch should be named "release-X.X.X", where X.X.X is the planned version number (without last build number, because it may eventually change).
Feature branch's name should carry the indication of the branch's purpose. It may start with "feature-" prefix for better visibility. It is recommended to give unique and expressive names. For example, "my_new_feature" or "my_work" are bad names, because they do not indicate the feature meaning. "new-script-commands" is not a very good name either, because there may be more than one branch dealing with new script commands.


Branch rules

All branches except "master" and "develop" are deleted some time after they were merged - to solidify their "finished" state (remember this won't delete commits, only branch's header).

The main "develop" branch is meant for working towards next major release. Sometimes it may be planned to make an intermediate minor release, or such need arises unexpectedly. This might be difficult to separate the development of minor and major version in time on one branch, so that major changes come only after minor ones and the minor release would not include them.
In such case it is recommended to create a separate branch named "develop-X.X.X" to work on minor update (where X.X.X is a planned version).
It is forbidden to have more than one major and one minor develop branches at a time. "Feature" branches should be used to work on and store code until the time when it may be merged into "develop".

After hotfix or release is merged into "master", it is recommended to merge them into nearest "develop" one (minor, then major) as soon as possible.
Similarily, when minor development branch is finished to be worked on (and new release branch spawns out of it), it should be merged into main "develop".
It is also recommended to merge "release" and minor development branches into main "develop" from time to time to keep things synced (especially if serious bugs were fixed in the former).

Feature branches carry little obligations. They may be postponed for undefined time, deleted, if appear to be a failure. They may be created solely to experiment on something.



Pull requests.

It is suggested to do most work on new features in personal repositories. Even if the developer has direct access to central repository, it is recommended to create personal branches when working on larger changes that require time to complete, review and test. This prevents from messing up commits from different developers, and also helps to distinguish commits related to certain feature or set of features.

Prior to other things, we recommend to setup a connection between your personal repository and central AGS repository. This page gives general tips on how to do this, and how to synchronize main branches between different repositories:
https://help.github.com/articles/fork-a-repo#step-3-configure-remotes
https://help.github.com/articles/fork-a-repo#pull-in-upstream-changes

Pull requests from personal repositories are used to merge developer's changes into central repository.
The most important rule for planned pull request is to work in a separate branch, even if the change is small, one branch per pull request, and one pull request for a feature or closely related set of small features.
This will allow you to keep your new feature code safe, not mess up irrelevant commits, and still be able to sync the main branches ("master", "release", "develop") in your personal repository with ones in central repository.
Remember that, if necessary, you may keep the feature branch unmerged for a long time, and merge only when it is most convenient to do so.
This is also important to remember that in most times there's no need to regularly update your feature branch with changes from "master" (or other main branches). Instead, if the main branch has changed too much, you may rebase your feature branch on top of updated main one. This helps to keep the feature branch and pull request cleaner, which also improves readability of changes history.

Pull requests should never contain irrelevant changes. Consider making two (or more) pull requests with different feature branches if all of those changes are required. If some changes are not needed at all, remove them prior to making pull request. Remember that Git allows to fix and copy branches and individual commits.
If you are making several minor changes that have similar meaning or related to each other consider making one pull request (these changes may be divided into several commits if wanted).

//===========================================
... to be continued with commit conventions.
//===========================================

Comments, suggestions, questions?

[First]

This is what I have to say.

I think that the arised problem is primarily a result of organizational failure. About 1.5 years ago we were discussing how to organize the work, yet, as time passed, it appeared that only JJS and me are working on the engine (and Tzachs was making few changes to the editor). Somewhere in early 2013 JJS became mostly inactive (IIRC he told me he is being busy with real life issues) and I suddenly found myself alone. Feeling pretty much baffled by this fact, at first I made attempt to develop engine further, without much understanding where I am going (the result is now known as AGS 3.4.0 alpha). When people started to actually using 3.3.0 beta, they began to find bugs and ask for more features, so I switched back to that branch, completely focusing on improving the release. Meanwhile, numerous organizational issues were stacking, without being resolved. At one point I made a promise to myself to deal with them after final 3.3.0 release, being afraid of getting lost working on multiple tasks at once. The monkey_05_06's commits to master branch caught me by surprise, because prior to that he had mentioned about his plans to work on updating Anroid port, but never about redesigning anything in the branch, which was being prepared for release.
(I'll put this just in case: this is not an excuse, but explanation.)

I believe that we need to make at least two immediate organizational decisions.

First, we need to activate the strict rule on branch usage. There was already a discussion on how to do this here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912 ;
if someone wishes to (re)state his opinion (whether accepting or declining) about this, I think this will be a good time to do so.
In brief, the idea was to not use master branch for anything but immediate hotfixes in case something is found completely broken there. The preparation for release should be done in a separate branch (e.g. release_3_3_0), further long-term development in "develop", separate features, which require serious changes or global redesign of code, - in their respected branches (preferrably created in personal repositories, rather than central one).

Second, there should be an agreement made on what is going to go to the 3.3.0 release.
My personal (but strong) opinion is that its development came to the point when it needs only careful polishing in order to make it as stable as possible, therefore no big changes should be applied in there, nor changes that do not explicitly fix incorrect behavior, but serve better program structure, class design etc; nor compatibility breaking changes - absolutely not.
Again, if someone has different opinion, please state it now.


Additionally, it would be very nice to decide a place to upload the binary dependencies, like AGS.Native.dll, which needs to be updated often. Git repository is not the best place for such files: compiled binaries compress badly, causing repository to bloat and people to get annoyed.

Then, after this is decided, we need to carefully fix the current master (so much as it requires) and proceed as planned.



On other issues.


I suppose that people involved in development should divide the parts of code/groups of tasks between themselves. I am speaking about timed division, not permanent. Such division should not prevent developers from discussing things others doing, or putting their own problems for public discussion. This should be done to avoid duplicating or contradictory changes, and to keep related changes and code more organized.
What is certain: if one at least suspects that his change will break what other is doing, the change should be discussed first, at least personally. Or, to put that other way: developer should at least warn about what he is willing to change, so that this change won't come as a total surprise.
I do not want to become paranoid from thinking that while I am working on a feature or a fix, someone else is doing the same (similar or other way).
Again, any possible tension may be easened by simply doing a work in a separate branch and/or personal repository prior to merging it with main development branch.
It also might be useful to make smaller commits, each related to one change or a number of strictly related changes. This will make it easier to pick out parts of code in conflicting situations.


If a developer is unsure about his change, and feels he is unable to come to decision himself, it is better to once again use personal repository to temporary keep the code for public review.
My suggestion is to keep central repository clean (without fanatism, ofc).


On breaking compatibility with anything.
This is not a simple decision, and there's usually a lot to consider. What is certain, if ever, this must not happen at random without preliminary discussion.
For example, here I started discussing breaking compatibility with old engine plugins: http://www.adventuregamestudio.co.uk/forums/index.php?topic=45810.msg636451744#msg636451744;
Compatibility with older games is primarily important for ports, because you cannot run original Windows executables on other platforms. If there will ever be a version which breaks compatibility with previous versions of AGS, a need will arise to maintain both old and new branches for ports, because the compatible branch may still require fixes and updates.


On changing/removing project settings, or any previously existing features.
There are several important points that must be tested when such change is done:
1. Test that the games created with new editor/engine build do work.
2. Test that old game projects could be loaded to editor, and still work with none or little updates to settings/scripts.
3. Test that older projects (pre 3.0) could be still imported and work "out of the box", with none or only little updates to settings/scripts. This may require converting old settings into new ones in such a way that'll allow to simulate old behavior with new features.
4. Test that the games created with previous versions of AGS still work as intended when ran with new engine. Similarily, some runtime data conversion may be needed.


On other branches.

The "develop" branch contains a lot of changes to the engine code, including several refactored classes and few more or less cleaned up routines (namely the evil dialog routine, that ran a "goto" controlled loop). Currently this branch is in a way separated from all other development, and as time passes, the situation becomes worse.
Hence this is my honest belief that "develop" branch should be considered as a place for any further code redesign and big updates.
The only big problem (AFAIC) about this branch is my ugly temporary solution for setting dynamic number of regions in the rooms. There was some discussion about how to solve this by introducing new UI component: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48513.0
If that (or any other solution) would be implemented, the "develop" will become practically ready for normal public use, if I may say so. (Still, as alpha, but at least people could use it without being confused about how to change areas count in the room).

The custom resolutions feature is currently floating somewhere in the middle (although logically more close to 3.3.0); it still requires improvement. The question is whether to continue developing it as a first successor to 3.3.0, or merge straight to "develop" (which version number will that result in - is something not of a real big concern). If the aforementioned "develop" issue would be properly fixed, there will be nothing that would prevent us from just merging everything in there, and have a combined "no limits"/"custom resolutions" build.

On some occasions, when running Editor in debug mode, I am being notified about assertions in Scintilla component.
This usually occurs when I open a script, select several lines, and hit Delete key.

For example:

Assertion [line < pdoc->LinesTotal()] failed at ..\scintilla\src\Editor.cxx 1932

Assertion [useCount == 0] failed at ..\scintilla\src\Editor.cxx 217

The raised assertion causes program to abort, which is pretty annoying; this does not happen in release version though.

Strange thing is that sometimes I can reproduce this over and over by quiting without save, reloading the project and repeating the action.
Then, at some point it stops reproducing...
Any thoughts anyone?

[UPD]

UPD: this was an experimental version. For more recent (and "more official") 3.4.0 version check this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51050.0
//---------------------------------------------------------------------------------



Since people keep asking about this , and I just happened to make a test build, here it is.
This is early work in progress. While I am generally optimistic about the feature itself, this build, in particular, is rather raw. That's why I do not publish source code. I will be rewriting it later anyway. In the end, I hope, custom resolution will make into one of the future "official" builds.

Version of 23 June 2014, updated to 3.3.0 update1.
http://www.mediafire.com/download/a1j4yu57gi46w2r/CustomRes_3_3_0_update1.7z
No-MP3 version of the engine:
http://www.mediafire.com/download/ntbvu97zaef0utv/CustomRes_3_3_0_update1_nomp3.7z
The complete source code contained in my personal branch here:
https://github.com/ivan-mogilko/ags-refactoring/tree/dirty_custom_resolutions


Preliminary version based on 3.3.1 alpha of 28 June 2014
(Warning: may be unstable)
(Includes Vertical Sync option for D3D9 driver in winsetup)
http://www.mediafire.com/download/i7bfqk5196azqhb/CustomRes_3_3_1_alpha1.7z
No-MP3 version of the engine:
http://www.mediafire.com/download/cac7brkaxz4f8dq/CustomRes_3_3_1_alpha1_nomp3.7z
The complete source code contained in my personal branch here:
https://github.com/ivan-mogilko/ags-refactoring/tree/dirty_custom_resolutions_331



Previous versions (some of them buggy):

Spoiler

Version of 6 February 2014, updated to 3.3.0 RC and added new winsetup:
http://www.mediafire.com/download/d4vz54sb4t33tma/CustomRes_3_3_0_RC.7z
No-MP3 version of the engine:
http://www.mediafire.com/download/aqda3dyndf8klht/CustomRes_3_3_0_RC_nomp3.7z

//---------------------------------------------------------------------------------------------

Version of 27 December 2013, which fixes sprite & font scaling:
http://www.mediafire.com/download/31qq2883hg6i5c5/AGS_CustomRes_Beta10_fix_27dec2013.7z
Also, source code in the form of patches (apply on top of "feature_display_resolution branch in ags repository):
http://www.mediafire.com/download/pdmzddcczl2afai/patch_temp_customres_beta10.7z

//---------------------------------------------------------------------------------------------

Version of 20th November 2013 (based on 3.3.0 beta 10, allows any custom game resolution):
http://www.mediafire.com/download/6yk5jmo1xlurfah/CustomRes_Beta10.7z
See info here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=49014.msg636473535#msg636473535

//---------------------------------------------------------------------------------------------

Version of 15th September 2013 (based on 3.3.0 beta 7, adds 1280x720 resolution):
http://www.mediafire.com/download/z52tkkuynk8z3sb/AGS_3_3_0_customres_test.zip
Adds only one new 1280x720 resolution.
Compatibility: this build can load game projects from 3.3.0 beta 7 and lower (e.g. 3.2.1).
1280x720 projects created with this build CANNOT be opened in 3.3.0 beta. Projects of other resolutions - may be.
WARNING! not thoroughly tested. Code-wise it potentially supports any resolution, but I did not have time to make a proper setup yet, so you can only set 1280x720 in the project settings. Also WinSetup displays incorrect information on resolution (this should not have any impact on gameplay).

[close]

I found that AGS setup can disable certain fields (checkboxes) and filters if their names are written in the cfg file in "disabled" section.
For example:

Code: text

[disabled]
speechvox = 1 // this disables "Use speech" checkbox
16bit = 1 // this disables "Downgrade 32-bit game to 16-bit" checkbox
filters = 1 // this disables filter selection, e.g. only preset filter can be used
StdScale2 = 1 // this removes "nearest neighbour x2" filter from the list

These settings may only be put into cfg by hand; Editor does not provide any means to set them.
What are practical uses for these? Have anyone ever used this opportunity?

Since it seems that people do not always figure out how the "code" tag works, there was an opinion that the '#' button in the post toolbar should insert [ code = ags ][ / code ].
Simply [ code ] does not work on the forums at all.

[WARNING: this forum thread describes very old experimental version that is no longer developed or supported.I do not recommend to use it.]

WARNING: this forum thread describes very old experimental version that is no longer developed or supported.

I do not recommend to use it.

AGS 3.4.0 Early Alpha

Warning! Warnung! Alarma! НевлезайÃ'Æ'бÃ'Å'Ã'‘Ã'‚! 我不会说中国话!

This is early ALPHA release. It is a work in progress, and may be generally unstable. Please, be cautious and backup your game before using this version.

Or rather do not use this version except for testing purposes, unless you are desperate to get its features.

*** Download as ZIP archive ***

The archive includes only Editor/Engine binaries. Make a clone of your current AGS program folder (tzach's 3.2.2 or newest 3.3.0) and then copy archive contents over.

1 jan 2014: Updated with all the 3.3.0 Beta 12 contents

Please, understand that this is work in progress. The further updates may include new features and fixes, as well as change or even remove existing ones. While I'll try to keep compatibility with game files created by earlier alpha versions, I give absolutely no guarantee about savedgame format (i.e. saves made with early alpha engine may become unreadable by later updates).
3.4.0 meant to be fully compatible with 3.2.1 and 3.3.0 projects and will try to upgrade them automatically.

This version still undergoes tests. There's chance I haven't noticed something and you will receive an error when trying to open a game project. Good luck .

So, what's in this version?

--------------------------------------------------
Limits removal
--------------------------------------------------
Following limits were updated:

Item	Old limit	New limit	Comments
State-Saving Rooms	300	999	Max room number is still 999
Dialog Topics	500	unlimited
Options per Dialog Topic	30	unlimited
Controls on GUI	30	unlimited
ListBox Items	200	unlimited
Mouse Cursors	20	unlimited
Room Backgrounds	5	unlimited
Room Objects	40	unlimited
Room Hotspots	50	256	restriction imposed by palette of a 8-bit mask
Room Regions	16	256	restriction imposed by palette of a 8-bit mask
Room Walkable Areas	15	256	restriction imposed by palette of a 8-bit mask
Room Walk-Behinds	16	256	restriction imposed by palette of a 8-bit mask
Custom Properties	30	unlimited
Overlays	20	unlimited

--------------------------------------------------
Features and behavior changes
--------------------------------------------------
1. Every room has now a "StateSaving" property, which should be set manually by user. Default is TRUE. When importing old project, rooms with id <= 300 will have this flag set to TRUE, others will have this flag set to FALSE.
This property may be changed freely at design-time, however this may cause strange results if you try to load older savedgames in new game version.

2. Room region/areas number is currently set manually by editing corresponding Room property (HotspotCount, RegionCount, etc). Take precaution, as decreasing this number will delete last areas in the list, including all their setup and mask parts. Which means, if you make a mistake, you'll have to repaint them (or reimport mask) again.
Be informed, that when importing old projects you'll likely want to decrease Hotspot number, because previous versions of AGS created all 50 of them for every room.

3. Custom properties can be changed at runtime, and stored to savedgames. For each GetProperty/GetTextProperty script function there's now a corresponding SetProperty/SetTextProperty function. There's still a restriction that you can only get/set properties that are in the Property Schema.

4. This version includes support for extended WFN fonts with 256 characters (by Alan v. Drake).


--------------------------------------------------
What's next
--------------------------------------------------

I thought about adding a TODO list here, noting most important advancements I had in plans, but I need to think this over again first.
I have literally no ideas on when the 3.4.0. will be "completed". There might be a lot of more things to come.

Currently I am considering looking into display resolution problem, then game resolution. We'll see...

Regarding limits, there are still few to remove. Some weren't removed simply because I forgot to (e.g. max Fonts, Animated Buttons) - I will fix this bit later, others are unlikely to cause problems (e.g. Drawing Surface limit of 20), the last require additional code rewriting. For instance, Inventory Item limit is affected by Plugin API interface as well. Then, a sprite cache system should be changed to allow having >30k sprites without adding problems.

I think I must tell about this, because it depresses me very much lately.
I made a very bad and rushed decision when I started to remake engine further: I continued to use the "partial upgrade" method by slowly changing parts of engine one by one, ensuring backwards compatibility working after every step, instead of writing essential parts anew and carry over compatibility later. Not only it took me more time working like this (because I had to break my head and make hacks after every change), but I now ended with a pretty ugly workarounds.
This can't keep going same way (not only technically difficult, but also psychologically exhausting for me).

However, redoing it right will take more time. Not only that, but, - let's put this frankly - I am quite tired now and can't promise I'll do this all soon. Perhaps I just need a change and forget about engine and this made up pressure for a while.

Therefore, this question is very important for me: is it worth to release this "raw" (or "alpha" if you like) version, forcing it to work by few more hacks? Are there people who would like to have new features regardless of risks? Assuming that I will be making few more fixes to support this "temporary" version.

The features I am speaking about are:

Spoiler

- unlimited number of state-saving room (max room count is still 999) and ability to select whether room is state-saving without setting ID > or < 300;
- unlimited number of dialogs and dialog topics; also option text of any length (not that it was important though)
- unlimited number of controls on gui; also Label/button/list text of any length;
- unlimited number of mouse cursors;
- unlimited number of room backgrounds;
- unlimited number of room objects;
- other room items are potentially unlimited too, but there is a problem with Editor UI lacking way to set their number; however I could, for instance, increase region/walkable area/walkbehind limit to match number of hotspots (50).
- unlimited number of custom properties; a way to change property value at runtime;
- unlimited number of overlays;

[close]