Messages

ListBox.FillSaveGameList() and ListBoxSaveGameList() are essentially the same thing, only called differently.
They both fill ListBox.SaveGameSlots AND savegameindex. And both arrays have size of 50 in the engine.

The savegameindex is declared with size 20 in the editor, though, which might be a mistake.

E: Right, forgot to tell, this was fixed in some of the 3.3.0 betas.

I think that immersion depends on combination of both view perspective and gameplay.

In my opinion, #1 is good when you want to show building entourage in most detail. On other hand #1 may be pretty annoying in case of real maze, because player may fail to see actual geometry of the base.
#2 is good when ability to actually see places you are going to beforehand is important (or required). It also gives better understanding of how places connect with each other, therefore is generally better for real maze.

To summ up: if it is not really a maze, and total amount of rooms is small, I'd prefer #1, because of, as you say, cinematic aspect.

I used Vista several years ago, and as far as I remember, it could be a bitch when it comes to access rights.

Anyway, as manual states, you can use following tags in the file path:

$SAVEGAMEDIR$, which allows you to access files in the save game directory.
$APPDATADIR$, which allows you to write/read files to a folder on the system which is accessible by and shared by all users

For example:

Code: ags

File.Open("$SAVEGAMEDIR$/hiscore.dat", eFileWrite);

I believe that should assure that the file will be properly created in Vista and Win7. At least AGS 3.* savedgames are saved properly on Vista, so other files might too.

Hmm... I think not.
This strikes me why it was never added.

I think a workaround is to fill the label with spaces, or, better, get Gui's drawing surface and draw string yourself as you like.

This all depends on what do you need the properties for. In many cases the solution might be to manually create dynamic array(s) of integers or strings in script, and use these instead.
Then, there's a properties module, that also allows to change their values at runtime: http://www.adventuregamestudio.co.uk/forums/index.php?topic=27385.0

Did that actually work in ATOTK?

No, but I never took it out.

Alright, that explains it all then.

By the way, the music jitter issues reported earlier do go away on an AGS build without multithreading (i.e. the most recent 3.3 beta).

Ok, I guess, we should disable that by default, maybe leaving an option in cfg file to turn it on for individual game/system if wanted. AFAIK mobile ports already have such option.

Monkey, I made a test, and it seems pretty clear now.

More info in github comments:
https://github.com/adventuregamestudio/ags/commit/0d6e8f67973a4508cf05e04d1e110f18c49b1e8c#commitcomment-4344864



EDIT:

Looking back on my code, ATOTK does the exact same thing as you recommended for Heroine's Quest: set talkanim_speed to GetGameSpeed() divided by some constant, to ensure that portrait animation speed remains the same when overall game speed changes.

Did that actually work in ATOTK? My test shows that in 2.72 Sierra speech does not use talkanim_speed at all.
I think that's the one confusing moment about this issue. I hope monkey_05_06 is correct in what he said above regarding possible bug report.
I will be able to test ATOTK in few hrs myself...

BTW, this seem to work in HQ3 private beta build that you gave me, it is built with 3.2.1, where talkanim_speed should already be in use by Sierra speech.
It probably will not work with 3.3.0 beta 8, because there's a mistake we are discussing now (it brings behavior back to 2.72 standards).

There was a number of errors found in the editor since I posted this 3.4.0 alpha build. These errors are fixed in 3.3.0, but not here.
I might find time to update 3.4.0 later on this week. Please, wait for several days. I am sorry for this inconvenience.

Although, I should warn once again, just in case, that 3.4.0 is not called "alpha" for nothing... I mean, it may be unstable and I may not be able to  fix it quickly.

people would find it much clearer and nobody would miss the other options

Err... I would definitely miss scaling filter option.

There appear to be few options that are not used anywhere in the engine. Might be deprecated or unfinished work.

There's whole bunch of command line parameters, but many have very specific meaning.
Here's most common ones:

Code: text

-windowed            Set display mode to windowed;
-fullscreen          Set display mode to fullscreen;
-hicolor             Downgrade to 16bit colors;
-letterbox           Enable letterbox mode;
-gfxfilter <filter>  Use graphics filter, where <filter> can be:
                     StdScale2, StdScale3, StdScale4, Hq2x or Hq3x
--help               Print this help message;

except that it would be nice to give the window the size of the entire screen, and add black borders around the (magnified) game screen.
<...>
I really think smart autodetection is the way to go here; you don't want to present users with a host of options if they aren't relevant to gameplay.

This is implemented in custom display resolution branch to certain degree: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609
It still requires some improvement, that's why I haven't put it in 3.3.0.

I believe you build with MSVS 2012?
There were problems when building Native with anything but 2008 SP1, usually related to linking third-party libraries.

Here are few older discussions that mention this problem:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46804.msg636448363#msg636448363
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46847.msg630136#msg630136
http://www.adventuregamestudio.co.uk/forums/index.php?topic=48009.0

JJS once mentioned it is possible to re-build allegro libraries in 2012. I suppose that we should not have pre-built libs at all (since people may use different toolset). Well, we never got to change that. Organization again... uh-huh.

I think the quickest workaround may be:

You may install minimal version of 2008 (Express) and still work in 2010 by doing this:

Open Project properties for the Engine project, "General" -> "Platform Toolset" -> should be set to v90.

Hopefully that'll work for AGS.Native too. Unfortunately, I can't remember if I ever tried myself.

In terms of organizing this project, I refuse to take any part in it. I will not participate in discussions about such things.

Well, can you at least give a hint what are you planning to work on in the nearest future?
I just want to have a trust that we understand each other.

[not]

This is not true. JJS implemented a "fix" because A Tale of Two Kingdoms was stupidly using this variable in the AGS game scripts but expecting it to do nothing.

I think I have a clue now (I hope it is true). If it used (set?) talkanim_speed, but the results remained the same, this means that talkanim_speed was ignored when the animation delay is calculated internally for sierra-style speech? But it is not ignored anymore in 3.2.1. If this is so, then there should be a fix not in the GetCharacterSpeechAnimationDelay(), but at places where it is used internally in the engine. Perhaps some other function should be introduced, that makes a backward-compatible runtime fix. Well, I replied the same on the github.
I'd rather suggest we make some tests with pre 3.1 games.

Well, at least Adeel had fun in this situation.

My apologizes again, I needed few days to calm down and think. As a result of thinking I started a new topic.

I want to mention few things about "Global speech animation delay support" feature. While I had no objections against a property (I guess it is pretty logical), but removing legacy setting completely is incorrect, in my opinion.
Leaving aside the problem with XML reader:
1) This setting was used when old projects (2.72) are imported. With this setting removed users will have to fix their game by setting the new property in script instead.
2) The old (< 3.1? )games with sierra-style speech always used a fixed animation delay (5). Now they will use game.talkanim_speed instead, which is probably set to 0 for all such games (the animation will run faster than intended).
3) I can't help thinking that it would be nicer to just rename this global setting, removing "legacy" word, and add a way to set talkanim_speed in Global Settings as well. This would allow average user to quickly set up his game's speech settings in properties, instead of script.
(the global animation delay option may hide when "Use *" is off, and appear when it is on, like some of the properties already do)

The only thing I may suggest is to try running it with a new version of the engine. Depending on what version of AGS the game was made with, this may have some compatibility problems though. 3.3.0 engine supports running games of v.2.5 and higher.

For more information check "Backward compatibility" section in the first post of this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47966.0

EDIT: Hmm, the topic starter mentions version 2.3. Is it the game of the same version? or exactly the same game? In such case my advice is not a proper one.

Something that would be nice to have in the setup program: "Autodetect Nearest Neighbor Filter". When selected and the game is run, this would look at the user's current screen resolution, and pick the largest multiple for the filter that fits on the screen.

This was implemented by BigMC for 3.3.0 long ago. The problem is that it only functions if there's no "gfxfilter" line found in winsetup. And Windows versions of the game usually comes with one (at least "gfxfilter=none"). I guess it is possible to add support for something like "gfxfilter=auto".


EDIT:

Would this be feasible to implement? This may be tricky for full-screen as you'd have to enumerate the possible resolutions for the monitor, but in windowed mode it sounds pretty straightforward.

Ironically, quite opposite, graphic driver API can always enumerate fullscreen modes, but they sometimes do not "want" to enumerate resolutions in window mode, because, usually, any window size is possible.

[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.

I apologize for everything I said here. I am genuinely ashamed and sorry.
This outburst was in a way unexpected by me. I guess I am just worrying about these things. Maybe to much. I don't have a right to behave like this.
I think I need to take a break.
Sorry again.