Adventure Game Studio

Hello,

I've been tinkering around with the AGS source for the last week or so. I'm mostly concentrating on some bugs that affect me, but I think they'll also benefit the community at large. Under Crimson Wizard's advice, I've also started back/forward/sideporting some of the changes in the Draconian edition to a format suitable for mainline AGS. Here are some things I am going to try to get into AGS 3.3.1. I'd like your feedback, comments, criticism, etc. I would appreciate code reviews, but I'd also just like general advice like "that's not important" or "we wouldn't want x option to work that way". I may change the target version for these, rethink them a bit or just scrap them completely.


Vsync for Direct3D
https://github.com/gurok/ags/compare/vsync (https://github.com/gurok/ags/compare/vsync)

This is something that Alan v.Drake implemented in his fork, but it was hard coded. The real problem with Direct3D and vsync is that it needs to be initialised before the game starts. Here's what I did to solve the problem:
There's now a new option in winsetup.exe called "vertical sync".
If it's checked, the game starts with vertical sync turned ON.
In DirectX 5 mode, the game can still toggle this setting with System.VSync.
In DirectX 9 mode, the System.VSync property becomes read-only.


Code Regions
https://github.com/gurok/ags/compare/code_regions (https://github.com/gurok/ags/compare/code_regions)

This is another thing I grabbed from Alan v.Drake's work. He added some directives to allow you to wrap sections of code arbitrarily, e.g.

#region
if(something)
{
...
}
#endregion

You could then fold the code to show or hide these regions. Useful for large, hard-to-maintain global scripts.


Software Sprite Scaling
https://github.com/gurok/ags/compare/software_sprite_scaling (https://github.com/gurok/ags/compare/software_sprite_scaling)

This was a common complaint when I was reading through a thread by Dave Gilbert about releasing commercial games with AGS (http://www.adventuregamestudio.co.uk/forums/index.php?topic=48795.0;nowap). In Direct3D mode, the sprite scaling uses the screen's resolution and not the game's. Nothing breaks immersion like pixels of different sizes. I thought about fixing the Direct3D implementation. The thing is, by the time sprites end up at the Direct3D, we have next to no information about what their "real" size should be. It turns out the code path for software rendering of sprites is still available to Direct3D, it's just not being used. This patch provides a new option in General Settings called:

Force software scaling and flipping

When set to true, it will tell AGS to use software scaling, regardless of whether Direct3D's "superior" hardware accelerated scaling is available.


For, Break, Continue
https://github.com/gurok/ags/compare/for_break_continue (https://github.com/gurok/ags/compare/for_break_continue)

This would be the first baby step towards making AGS a more C-like language. I read a thread a while ago where CJ mentioned that for() and do and things like that were just duplications of while(). I don't agree that we should be limited to only using while statements. There's something to be said for the readability that comes with a standard set of control statements. That's why I'm proposing three new commands:

for([initialisation]; [check]; [increment])
{
    ...
}

continue;

break;

This would be the first step toward a more expressive AGS scripting language. I know there have been efforts to introduce LUA in the past, but this is something that can work immediately. In the future, I would plan to introduce more statements, like switch() and do, as well as struct parameter passing.

Technically speaking, the jumps for all of these commands already existed in the AGS code. There's a slight modification (some two phase parsing) needed to parse the increment of a for loop, but nothing more than what happens when calculating the jump for a while loop. I also refactored the parsing of assignments (first part of a for loop) to allow for this change.

This is a change that I think would need some serious testing. Everything it generates is stuff other commands generate (JZ, JMP, MOV, LITTOREG, etc.), but it's possible to seriously screw up a compile if some of the code is wrong. The good news is, if there are bugs, you can just remove the for, continue and break statements from your code and everything should function as before.

In terms of efficiency, continue is very efficient if it eliminates a check e.g. if(continue == true). Break involves the same number of jumps as a normal loop termination. There was no way to eliminate the second jump required. The for loop should be about as efficient was writing out a similar while loop by hand, e.g. x = 0; while(x < 10) { ... x++; }.


Portrait Positioning
https://github.com/gurok/ags/compare/portrait_positioning (https://github.com/gurok/ags/compare/portrait_positioning)

Here is my unanswered thread about this problem:

http://www.adventuregamestudio.co.uk/forums/index.php?topic=49927.0 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=49927.0)

The positions for character portraits are sticky because AGS has no idea of who was talking before the current character once the speaking character has actually changed. My solution was to implement a two object "stack" of actively speaking characters. That way, if a character speaks, moves and speaks again, AGS still knows to whom that character was speaking and can use the relative position of the character to determine which side the portrait should be on.

If the speaking character is the first character to speak when entering a room, AGS takes a guess at which character they're speaking to by grabbing the first character it can find. I thought this could be a bit smarter, so I made it assume the character speaking was talking to the player first (if applicable), then try any random other character in the room.

This is a bit of a personal bugbear as X-based positioning for character portraits is unusable for me right now.


Text Window GUI Padding
https://github.com/gurok/ags/compare/text_window_gui_padding (https://github.com/gurok/ags/compare/text_window_gui_padding)

This is one of the first things I proposed to CW and it's looking like 3.3.1 will be the release this makes it into.

It's very simple. Currently, text window GUIs put an amount of padding around the text in them. It turns out that this padding was a hard coded 3 pixels. This change adds a new property called "Padding" to text window GUIs and allows you to adjust this value (default is 3). I can't believe there haven't been any other complaints about this. It basically makes it impossible to make tight speech windows.


--

I'm currently focused on porting the stuff from Alan v.Drake that's still relevant. I might add to this discussion when I've got a list of the new scripting commands he added. Some of them will need to be discussed. People tell me to check the bug tracker. I've had a look there, but I also need to pick and choose things I can actually do. A lot of those tasks seem enormous and I'm only just finding my feet in the AGS source.


P.S. CW, is this the sort of discussion you were after?

All looks excellent and extra kudos for providing actual implementation and not just whining like the rest of us.

I think the thing that almost everyone is most interested in is struct parameter passing.
My suggestion for actual object creation can be found here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46157.msg620208#msg620208

Thanks. I'll take a look at it.

Wow, great to get another coder involved!

These look like fine improvements. I personally really appreciate vsync and for-loops. (And yeah, if we could pass pointers to custom structs, that would simplify coding by about 1000% percent.)

I do wonder about this bit, though:

Quote from: Gurok on Sun 09/02/2014 08:45:13
Software Sprite Scaling
https://github.com/gurok/ags/compare/software_sprite_scaling (https://github.com/gurok/ags/compare/software_sprite_scaling)

This was a common complaint when I was reading through a thread by Dave Gilbert about releasing commercial games with AGS (http://www.adventuregamestudio.co.uk/forums/index.php?topic=48795.0;nowap). In Direct3D mode, the sprite scaling uses the screen's resolution and not the game's. Nothing breaks immersion like pixels of different sizes. I thought about fixing the Direct3D implementation. The thing is, by the time sprites end up at the Direct3D, we have next to no information about what their "real" size should be. It turns out the code path for software rendering of sprites is still available to Direct3D, it's just not being used. This patch provides a new option in General Settings called:

Force software scaling and flipping

When set to true, it will tell AGS to use software scaling, regardless of whether Direct3D's "superior" hardware accelerated scaling is available.

Is it not possible in D3D to simply "merge" the background + all the sprites and stuff onto a single texture in the game resolution, and then scale up that texture to the screen/window resolution, all with hardware acceleration? I don't know that much about 3D programming, but that seems like the "right" way to do it.

Yea, I meant to mention this. Using software scaling is not the right solution.

A better solution would be to have a RenderTarget of the native game resolution, do *all* drawing to that and then draw that RT to the back buffer.
That way you can still utilise filtering of various kinds and it still make sense with regards to the native res.

Well, my D3D driver handled scaling just like that. Are you doing this via software so you can apply non-shader filters afterwards ? I always wondered if it's faster to get a bitmap from the d3d surface and then feed it to the filter and back. Shaders would still be better tho.

- Alan

Quote from: Alan v.Drake on Sun 09/02/2014 14:50:26
Well, my D3D driver handled scaling just like that. Are you doing this via software so you can apply non-shader filters afterwards ? I always wondered if it's faster to get a bitmap from the d3d surface and then feed it to the filter and back. Shaders would still be better tho.

- Alan

I'm doing this because I didn't know you'd implemented better scaling. If your D3D driver did scaling as Snarky described, then maybe it's better to kill off my proposal and browse through the Draconian fork instead.

I actually thought there were complications involved with rendering to 320x200 and then upscaling it. I'm pretty sure I've seen some AGS games that are 320x200 but have high resolution fonts. Don't know how they work, but that was part of my concern. Also, I did it this way because the patch was minimal and it was relatively easy to do so (not so good reasons, I know).

I have heard there are some problems with filters in direct 3D, so maybe that's another reason to allow software scaling. But at the moment, I'm getting the strong impression that I should just ditch the current effort and do it the "proper" way.

I am looking at passing structs, Snarky. No fancy class keyword or allocation on the heap, but passing them in seems doable.

Looking great!

For loops are a welcome addition, and text window padding especially has been a pain. While you're working in that area, maybe you can look into having the line & character spacing also configurable (not only in text windows, but in Say commands as well) which would also help make some fonts more readable.

Quote from: Gurok on Sun 09/02/2014 15:04:09
I actually thought there were complications involved with rendering to 320x200 and then upscaling it. I'm pretty sure I've seen some AGS games that are 320x200 but have high resolution fonts. Don't know how they work, but that was part of my concern. Also, I did it this way because the patch was minimal and it was relatively easy to do so (not so good reasons, I know).

Yeah, in earlier versions of AGS it was possible to make a 320x200 game and then set it to run in 640x400, which made the fonts display in twice the resolution. Some games (notably the Blackwell titles) took advantage of this. That feature-slash-bug was removed in recent versions, though (3.0, maybe?).

There's been some talk about allowing mixed-resolution games in a more deliberate way. (Perhaps an option to render fonts in a separate layer in the native screen resolution? Or a way to define certain graphical elements as being pre-scaled...) CW seemed to think it would make the graphics rendering code very messy.

(If we're talking feature requests, by the way, it would be cool to have the option to place sprites and text at non-integer coordinates. That would make smooth scrolling look better. Also higher resolution on sprite transformations like scaling and rotation: only having whole-percent and whole-degree accuracy makes these operations pretty jerky.)

I made "develop-3.3.1" branch in central repository, so any updates may be pushed there.

Quote from: Snarky on Sun 09/02/2014 16:11:15
(If we're talking feature requests, by the way, it would be cool to have the option to place sprites and text at non-integer coordinates.

I must remind (again) that in AGS everything is interwined and one problem is usually blocked by another. It is of utmost importance to find the blocking issues, plan and resolve them first.
This, for instance, will require changing Plugins API, because current one has inner data of many engine types exposed.
Also, - providing compatibility hacks for old games that change object coordinates by writing directly to memory address.


I also urge you (practically beg) not to get every idea in one pile (again), regardless of how cool and wanted it is.
My belief is that the milestones for the next major version should be defined first (considering blocking issues too), and the work continued in a more advanced "develop" branch. As for 3.3.1 version, it should receive only minor updates that do not require changing the code much.

Quote from: Crimson Wizard on Sun 09/02/2014 17:04:50I also urge you (practically beg) not to get every idea in one pile (again), regardless of how cool and wanted it is.

That's a good point. How about, instead of placing six ideas in one thread, we open six separate tickets in the Bugs And Suggestions Tracker?

QuoteMy belief is that the milestones for the next major version should be defined first (considering blocking issues too), and the work continued in a more advanced "develop" branch. As for 3.3.1 version, it should receive only minor updates that do not require changing the code much.

I agree that's a good approach.

Gurok made few merge requests, namely for:
- Code regions
- Portrait positioning
- Text window gui padding
- Vsync

If I understand correctly, there were no objections against these? These changes seem pretty simple ones.
I really hope Gurok tested them, especially the ones with padding and portrait positions (that all alternate options still work properly). :)
But since we are talking about development branch, it won't be a big problem if there are bugs there. I may merge them right away, then we may have the first test build.



Additionally, I can merge the long waiting feature branch by Alan v. Drake with his new script commands (extended Character.ChangeRoom function, etc):

void Character.ChangeRoom(CharacterInfo *chaa, int room, int x, int y, CharacterDirection direction);
int Object.IsInteractionAvailable();
int Hotspot.IsInteractionAvailable();
int Character.IsInteractionAvailable();

(or pick out the code manually to make it cleaner and easier to merge)
It bothers me that IsInteractionAvailable() returns "int". Since the return value is not used in binding script to engine, maybe it will be possible to change it to "bool" and still have compatibility with Draconian games.

EDIT: hmm, after rechecking the old branch, I think it will be easier to remake all them, because there's some excessive code in there (like ChangeRoom function have an "old-style" duplicate).

I really hope I tested them too!

Portrait positioning only applies to really specific cases. The code I changed is after a series of checks that go a bit like this:

if(using_sierra_style_portaits)
    if(not_using_full_screen_ones)
        if(using_portrait_x_positioning)
            ...

Text Window GUI padding applies to all text windows. I tested speech and Display("") windows thoroughly. Both with border graphics and without. Is there anything else?

For, continue and break is the one I'm most concerned about. For a while, I accidentally had my for loop behaving a bit like a "yield" statement. It would quit the function and the next time you called that function, it would resume from that point. Finally tracked it down to a missing continue statement in cc_parser. That's why I'm concerned about merging that branch for now (at least until I've had more time to test it).

I found a bug in TextWindow padding feature: it does not set a default padding value when loading old projects into editor. This means that all previously created projects will get padding set to 0.
How to fix: assign default value with member declaration instead of base constructor:
private int _padding = 3;
(remove the "_padding = 3;" in TextWindowGUI() constructor).

Remember that you can do "ammend commit" thing to fix already existing commits, and "force push" to update your remote branch (Never do that in master, because that may cause conflicts with other people's work, but temporary feature branches are OK).


EDIT: Hmm, I forgot another case: importing a 2.72 project. It is done in a separate function in agsnative.cpp. We need to test that too.

All done. Sorry. I honestly thought the base() function was handling that. :/

REPLY TO EDIT: I believe this is already covered in my changes to read_gui:

    if (GameGuiVersion < kGuiVersion_331)
      guiread[ee].padding = TEXTWINDOW_PADDING_DEFAULT;

But that's a good point. I haven't tested it against 2.72.

2.72 import is broken in 3.3.0 :(. I already found what caused this, there will be a fix soon.

Is there a convenient link to 2.72 so I can do testing against it in the future?

Quote from: Gurok on Mon 10/02/2014 11:41:35
Is there a convenient link to 2.72 so I can do testing against it in the future?

All here: http://agsarchives.com/engine.html ("Other builds" list at the right side).


EDIT: tested with fixed 2.72 import, it's working and padding = 3 for text windows.

Has anyone proposed closures or lambda expressions in the AGS language? Or at least the ability to pass function pointers like in C and execute it.

I think thats a little beyond scope at the moment.

If you need that then I suggest the AGS Lua plugin.

Gurok, I could not find time to check the for/continue/break feature yet.
Maybe you could make a test build and let people try it out meanwhile? You need to distribute only Editor & Engine binaries (dlls and exes), they may be manually copied over 3.3.0 folder.

The code changes in case anyone's interested to review: https://github.com/adventuregamestudio/ags/pull/121/commits

Quote from: abstauber on Mon 10/02/2014 10:00:18
But pretty pretty please consider fixing the Undo-History :~(

To be honest this is driving me nuts, because at some points I can't remember what I did to break the game. Only that now I can't undo my way out of this mess ;)

Yes, for me this is a no-go for upgrading to 3.3.0. I tend to do tests by changing parts of the code, then undo the changes. If the undo history is gone, I'm done for.

You could test your code by doing this:

/*/
// Original code -- COMMENTED OUT
int a = 42;
float b = 3.14;
String c = "blah";
// ...
/*/ // don't mess with this ;)
// New code -- NOT COMMENTED
int a = 314;
float b = 5.7;
String c = "whatever";
// ...
/**/

/**/
// Original code -- NOT COMMENTED
int a = 42;
float b = 3.14;
String c = "blah";
// ...
/*/ // don't mess with this ;)
// New code -- COMMENTED OUT
int a = 314;
float b = 5.7;
String c = "whatever";
// ...
/**/

By changing a single character (the asterisks on the first line) you can toggle between the two blocks of code.

Tzachs is testing the fix in the 3.3.1 branch right now.

Also, have anyone tried to use source control with AGS? There's even a plugin api for that.

Quote from: monkey_05_06 on Wed 19/02/2014 16:26:30
You could test your code by doing this:

Nope. It's not a matter of replacing an entire section of code with another one. It's a matter of modifying a bunch of small parameters inside the code, and continualy testing what the changes did.
Anyway, just sayin'.  For me it would be disastrous not to be able to revert after I inadvertently broke something at some unknown point. It's only an inconvenience for me, others will do great.

Quote from: Crimson Wizard on Wed 19/02/2014 17:03:33
Have anyone tried to use source control with AGS? There's even a plugin api for that.

I can't wait for that to fully mature. I'm very excited.

Quote from: Monsieur OUXX on Wed 19/02/2014 17:49:13
I can't wait for that to fully mature. I'm very excited.

But you can use any version control system right now. For scripts, at least.
BTW Git is good for experiments, because it allows to quickly switch between branches.

Doing what you say with Undo sounds like a wrong thing to me anyway.

Quote from: Crimson Wizard on Wed 19/02/2014 18:10:46
Doing what you say with Undo sounds like a wrong thing to me anyway.

OK guys, you win, I'll stop being stubborn and switch to 3.3.0. I'm very attracted to source control and re-importing sprites from original source.

Quote from: Monsieur OUXX on Thu 20/02/2014 11:13:23
OK guys, you win, I'll stop being stubborn and switch to 3.3.0. I'm very attracted to source control and re-importing sprites from original source.

I was not forcing you to use 3.3.0 :), in fact the non-working undo is something I would be concerned about as well.
Regarding source control, I mean it can be used normally without connection to AGS. You may just make a repository out of the game project folder.
I don't know how source control API works myself.

An alternative implementation of version control could be a simple visual interface with Git, using system calls (an API would be a better choise). A version of Git could be placed in the AGS folder on the next release. Each project folder would have a local repository, and may have a pre-configured .gitignore to ignore some files. To support remote repositories the user may enter with a Github URL in the project creation wizard, or set it later in the project settings.

Just a sugestion! :wink:

I worked closely with CJ in designing the current source/version control API for editor plugins, but I could never seem to quite wrap my own head about how to properly implement any of the systems I looked at. I knew less about version control then than I do now (which is still not very much), so I may take a look at it later and see if I could come up with anything.

Quote from: monkey_05_06 on Sat 22/02/2014 06:23:47
I may take a look at it later and see if I could come up with anything.

Please do it. AGS needs collaborative development.

Quote from: Monsieur OUXX on Sat 22/02/2014 19:04:08
Please do it. AGS needs collaborative development.

AGS and the AGS Git repository both!

I can't say anything to the Direct3D stuff. I'm not enough experienced with it.
The "for()" statement would be a nice-to-have feature. (I can't say why I didn't missed it so much.)

To having pointers as member variables of structs would be fantastic!

Quote from: Crimson Wizard on Thu 20/02/2014 11:26:04

Quote from: Monsieur OUXX on Thu 20/02/2014 11:13:23
OK guys, you win, I'll stop being stubborn and switch to 3.3.0. I'm very attracted to source control and re-importing sprites from original source.

I was not forcing you to use 3.3.0 :), in fact the non-working undo is something I would be concerned about as well.
Regarding source control, I mean it can be used normally without connection to AGS. You may just make a repository out of the game project folder.
I don't know how source control API works myself.

Crimson is right. A version control system will resolve your problem to determine which code lines you changed. And, it will allow you to keep a history of all your changes.
I installed a subversion repository on my machine (using TortoiseSVN) and added the project folder as trunk as Crimson also mentioned.
The repository also allows you to branch and try out another AGS version.

Hello all,

I've found some more low-hanging fruit. It's pretty easy to lift the static restrictions on extender functions such that you could do this:


static function DoIt(this Character *, int a)
{
    Display("I did it! %d", a);
}

and then in your module header, this:


import static function DoIt(this Character *, int a);

and then later somewhere in your code, this:


    Character.DoIt(3);

The trouble is that
a) "this" is not defined for a static extender function
b) the syntax is a bit ugly

"This" being undefined is not such a problem because the compiler picks that up anyway. If I were to tidy up the syntax (which I could), do people think this might be useful? Something like this might be possible for the syntax:

static function DoIt(extends Character, int a)
or this (which is the nicest I've thought of so far):

function AbsInt(static Maths, int value)

Though I am open to suggestions.

I've also devised an extraordinarily complicated way to do switch() statements if anyone's interested. This:


switch(x)
{
case 5:
Display("Five");
case 6:
Display("Six");
default:
Display("Default");
case 7:
Display("Seven");
}

translates into lots of jumps. Pseudo-assembly follows:


# Switch statement
jmp condition1:
exit:
jmp 0
condition1:
evaluate_expression("x == 5");
jz condition2:
code1:
Display("Five");
jmp code2:
condition2:
evaluate_expression("x == 6");
jz condition3:
code2:
Display("Six");
jmp code3:
condition3:
# No jumps or evals
code3:
Display("Default");
jmp code4:
condition4:
evaluate_expression("x == 7");
jz 0
code4:
Display("Seven");
end_of_statement:

With the 0 addresses being filled in as "end_of_statement" after the switch statement is fully parsed
Might need some temporary 0 addresses for lines like "jmp code2:" too
But with this, a break statement just becomes:


# Break statement
jmp exit:

I haven't coded the above yet, but that is what I plan to do. Comments welcome.
AGS script is a single pass compiler, so there are a lot of cases where jmp 0 is used temporarily. A few variables about how things are currently nested (almost to the point of having a second pass) are stored to help fill in the blank addresses later.

Side note: Passing structs as parameters is more complex than I first thought and might take some time.

Static extenders would be great. I've come across several times where I had to resort to some annoying alternatives.

As to switch statements, I don't understand these things well enough to know any better, but you've said that it's a rather complicated solution, might there be a better way?

If you can figure out passing struct instances by reference as well then everyone can finally stop complaining about how horrible AGScript is.

Static extender functions

Syntax as follows.

Module:

function AbsInt(static Maths, int value)
{
    if(value < 0)
        value = 0 - value;

    return(value);
}

Header:

import function AbsInt(static Maths, int value);

Example call:

int x = Maths.AbsInt(-3);

https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_static_extender_functions (https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_static_extender_functions)

Better warning for function delcaration inside a struct

https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...bugtracker_function_in_struct_error_msg (https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...bugtracker_function_in_struct_error_msg)

http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0 (http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0)

--

I should probably listen to CW's advice and stop piling features into this thread. It's just every time I look at the scripting engine (and this weekend I spent some time looking at for/break/continue), I see things which could very easily be made better.

Quote from: Gurok on Mon 10/03/2014 06:25:49
Side note: Passing structs as parameters is more complex than I first thought and might take some time.

You might need to make a new type of dynamic object manager in the engine that handles user structs.

Quote from: Crimson Wizard on Mon 10/03/2014 15:06:51
You might need to make a new type of dynamic object manager in the engine that handles user structs.

Yes, that is what I fear :D. Right now, switch...case seems easier. Also I've been trying to fix general bugs, but I find myself drawn to the script compiler.

Hmm, no, I mistook dynamic creation with passing reference.
For passing reference you will need just a wrapper which knows the type of data ("user struct reference"), address and size, and you may "simply" use RuntimeScriptValue for that.

Dynamic creation of user structs is different thing. You might have a look at how strings and dynamic arrays are created: there's a special assembly command for that. But this would be a completely new feature.

I had that working for global variables, but not stack variables. Some wrinkles in addressing that weren't immediately apparent. I'm going to pull it apart and try again, of course.

Is it possible for me to close issue 503? http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0

I'm going to make a new thread, "AGS 3.3.1 - Test Build" with a changelog and download link tonight.

Quote from: Gurok on Mon 10/03/2014 22:16:17
Is it possible for me to close issue 503? http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0

I don't think it is correct to close issues in AGS tracker before at least some public release is made. But that's my opinion.

Quote from: Crimson Wizard on Mon 10/03/2014 22:56:02

Quote from: Gurok on Mon 10/03/2014 22:16:17
Is it possible for me to close issue 503? http://www.adventuregamestudio.co.uk/forums/index.php?issue=503.0

I don't think it is correct to close issues in AGS tracker before at least some public release is made. But that's my opinion.

Oh right, yes. Sorry. I agree. A bit too hasty by me there.

I am thinking of possibly allowing an empty statement, i.e.:
;
As a valid AGS Script statement. How do people feel about this? At the moment, the compiler rejects it.
Pros:
    - More C-like
    - Allows for neat for/while loops that repeatedly call an iteration function
    - A good placeholder when you need to fill in the if() part of an if/else later on
Cons:
    - Allows users to possibly make errors by accidentally terminating a for/while loop with a ;

I'm generally in favor of mimicking C-syntax as much as possible. FWIW I occasionally use { } already as an empty statement.

Hey Gurok (and devs),
since you're currently working on 3.3.1, would it be too much to request this feature:

Only these two functions are missing to make dialogs completely controllable via keyboard which is what I'd like to do:

    Dialog.SetActiveTopic(int option)
    Dialog.StartTopic(int option)


Currently you can only start a complete dialog by script and the only way to highlight a dialog topic is via mouse-over.
If it's not too much work, I'd be really happy to see this in 3.3.1

Quote from: abstauber on Thu 13/03/2014 10:14:11
Only these two functions are missing to make dialogs completely controllable via keyboard which is what I'd like to do:

Code (ags) Select Expand


    Dialog.SetActiveTopic(int option)
    Dialog.StartTopic(int option)


Raise a bug tracker suggestion for these.

I understand Dialog.StartTopic() as I've run into that limitation myself. What would SetActiveTopic be for?

I raised a suggestion for the scripting changes I think I'll be able to do (not closures or function pointers or outlandish stuff like that). In some ways, I think this topic was a bit of a mistake, but it's been good to gather feedback.

I think your second function is doable at some point, abstauber. I don't know about the first.

I think "Active" is the one selected (highlighted).
I am not sure about "Topic" word. Other functions use "Option" (compare with Dialog.GetOptionText, Dialog.GetOptionState etc).

Quote from: Crimson Wizard on Thu 13/03/2014 11:12:08
I think "Active" is the one selected (highlighted).
I am not sure about "Topic" word. Other functions use "Option" (compare with Dialog.GetOptionText, Dialog.GetOptionState etc).

Yeah, that's what worries me. As far as I remember, dialogs run without really having the concept of a selection. They only have a mouseover state. Unless he means "choose this choice for the player" like how the 0-9 keys behave currently.

@abstauber, have you tried using DialogOptionsRenderingInfo.ActiveOptionID ? I think it is what will let you set highlighted option with keyboard (or in any other way).
Of course this will only work if you write all the other handlers for custom dialog rendering too.

"StartTopic" (or RunOption, whatever) might be still required though.

As far as I remember, the custom dialog GUI only updates its surface when a dialog option is changed or the mouse hovers over an option. So even if I set the active ID, I'd still need to tell the GUI to update.
So simply setting the highlight by a number would be way more convenient.
And yes - dialog Option makes much more sense than topic :)

QuoteRaise a bug tracker suggestion for these.

Will do.
edit: but I can't. Do you need a special role for this?

As CW mentioned, dynamic creation of user structs is quite involved.

I haven't coded this yet, but I was thinking something like this might work for passing structs without needing to manage them:

Header

    struct Point
    {
        import static Point *Create(int x, int y);
        import float DistanceTo(Point *target);
        int X;
        int Y;
    };

Module

    static Point *Point::Create(int x, int y)
    {
        Point instance;
     
        instance.X = x;
        instance.Y = y;
     
        return(&instance);
    }
     
    float Point::DistanceTo(Point *target)
    {
        int dx;
        int dy;
     
        dx = this.X - target.X;
        dy = this.Y - target.Y;
     
        return(Maths.Sqrt(IntToFloat(dx * dx + dy * dy)));
    }
     
Example Usage

    float myFunction()
    {
        Point a;
        Point b;
     
        a = *Point.Create(3, 3);
        b = *Point.Create(6, 7);
     
        return(a.DistanceTo(&b)); // 5.0
    }

Too complicated?

Quote from: Gurok on Tue 17/06/2014 23:55:50

Code Select Expand

    static Point *Point::Create(int x, int y)
    {
        Point instance;
        <...>
        return(&instance);
    }
    }

This looks like a very bad idea. You are going to return an address to object, allocated on stack. Besides, there's no '&' as "take address" and '*' as "dereference" operators in AGS... and for a reason: AGS was made as a Java/C#-like language, and you are suggesting to "downgrade" it to C-like language.
I still believe that managed user structs is an only proper way to go.


And, yes, I am back... I was away, then busy, then ill :-X. Now trying to finish unfinished business...

I agree with CW. This is, at best, a hacky stopgap.

The pointer syntax in AGS is a weird anachronism as it is and shouldn't be expanded.

I think it would be better to move towards true object references.

AGS does have a way to add arbitrary structs to the object pool via the plugin interface. Is it a huge deal to simply expose this to the script env?

Just few thoughts (I'd need to refresh memories about script interpreter before I can be more specific).

To have a managed user struct you need an object that will describe it. Possibly, it only needs two properties: size of struct (in bytes) and pointer to data (array of bytes).
Then, you need a manager class that would handle such objects to integrate new type into AGS (manager class and object class could be the same).
Then, it's only a matter of making two additions:
- "new" keyword which would allocate object of desired size on heap and assign to reference; one may look into how script strings and dynamic arrays are created.
- if proved necessary, extend "access member" operation to ensure that it works well with the new type.

BTW, I think, dynamic array type may be a good example to how managed object and manager classes should work, principally.

Quote from: Crimson Wizard on Wed 18/06/2014 12:25:25

Quote from: Gurok on Tue 17/06/2014 23:55:50

Code Select Expand

    static Point *Point::Create(int x, int y)
    {
        Point instance;
        <...>
        return(&instance);
    }
    }

This looks like a very bad idea. You are going to return an address to object, allocated on stack. Besides, there's no '&' as "take address" and '*' as "dereference" operators in AGS... and for a reason: AGS was made as a Java/C#-like language, and you are suggesting to "downgrade" it to C-like language.

Yes, I know the object's allocated in stack memory, but it *kind of* would have worked for unmanaged structs as long as there were never pointers to them.

Anyway, yeah, looking into getting the "new" keyword working properly now. I've been messing around with things for about a day now and I feel /slightly/ more informed. There's a surprising amount that's already built. If you declare a struct as managed, you can have pointers to it and it compiles. You just can't do anything useful with it. So you're right. The "new" keyword is like the missing puzzle piece. Thanks!

If you can make that work then you'll have gone a long way towards "fixing" AGS Script.

@Gurok
I made this patch (applied on develop-3.3.1): http://www.mediafire.com/download/g2wnuyfqzodn89l/0001-Script-managed-user-object-support.patch
It adds user object support to the engine. Unless I miss something, this is about all what is required for the Engine.
The compiler needs:
1) support for creating managed user objects, e.g. via "new" keyword. I made new "SCMD_NEWUSEROBJECT" command for that (takes one argument - the size of struct in bytes).
2) "legalize" usage of user pointers (MyStruct *p) so that they could be used in similar way as built-in classes (Character*, etc).
The access to object contents is performed same way as you do for internal variables in built-in structs (legacy scripting).
I don't know compiler well, but you seem to be able to get around it.

Let's try this...

EDIT: found a bug, reuploaded patch... (same link).

EDIT2: reuploaded second time :tongue:.
I did not realized that the command should take 2 parameters: register number (to save new pointer) and struct size.

Final patch for Engine: http://www.mediafire.com/download/g2wnuyfqzodn89l/0001-Script-managed-user-object-support.patch

Test patch for compiler (breaks managed arrays, but this is for test): http://www.mediafire.com/download/0safjx7itsh118l/0001-Compiler-TEST-creating-user-object.patch


Proof :D:

Spoiler

Script:
(http://i.imgur.com/xERvMfm.png)
Result:
(http://i.imgur.com/u3bjBsE.png)

[close]

monkey should be happy. No more Lua, mwh-mwhahah. (kidding)


TODO:
1) proper compiler patch (I really hope Gurok will make one, I made this test rather intuitively).
2) support for array of user objects.
3) test all possible cases.

Whoa

One more TODO... I was going to change the compiler to allow structs to have functions with the same name, e.g.

managed struct MyStruct
{
  import function MyStruct(int a, int b);
}

It's a simple patch, replace "(towrite != in_struct_declr)) {" in cs_parser.cpp with "(towrite != in_struct_declr || sym.stype[last_time] == SYM_VARTYPE)) {"

And the "MyStruct" function would act as a constructor, e.g. x = new MyStruct(3, 4);

Then it's just a matter of parsing a function call after each new statement is parsed.

I'll have a look at your new Editor patch before I start on a proper branch, CW. This is so cool.

If you've seen the part where it parses an array, I think that's the right place to put the managed struct stuff too. It's just a matter of having an if() statement like...

If the symbol following the var symbol is not "["
  ... managed struct creation code ...
else
  ... dynamic array creation code ...
end if

Anyway, really exciting! Awesome work, CW.

EDIT: Saved games (serialisation/deserialisation) would be one of the first things I'd like to test. Anyway, I'll get to work on this, sorry! :D

Right, constructor is the most logical thing to add.

Regarding serialization, all managed objects work via same interface, so its only a matter of writing/reading memory properly. In the case of "user object" it simply copies N bytes.

This is fantastic! I have all kinds of stuff I'd like to use this for.

Thats fucking cool guys.

I will be releasing some modules for this!

I think a constructor would be great and a destructor might be cool (?)

static methods should already work right?
Do properties work? I forget what AGS calls them.. attributes i think.

Properties fail to work for some reason (unresolved import with weird error message).
I suspect that compiler needs to handle special case there.

This is really awesome. Excellent work, guys, and keep it up!

Quote from: Crimson Wizard on Tue 01/07/2014 16:08:54Properties fail to work for some reason (unresolved import with weird error message).
I suspect that compiler needs to handle special case there.

Actually, they work fine (http://meleepta.x10.mx/ags/3.3.1-Attribute-Test.rar) (download my test case). Since you're working with a user-defined type, the user also has to define the accessor methods. I've used extender methods so the accessors don't show up as normal member methods, but it is apparently working! :) And just in case anyone hasn't seen it, the attribute tutorial in the wiki (http://www.adventuregamestudio.co.uk/wiki/Keyword:_attribute) is probably a good place to start.

The one issue I did have was with a static method returning a new pointer to the user type. The compiler complained that the "Size of identifier does not match prototype":

managed struct UserObject
{
  import static UserObject* Create();
};

static UserObject* UserObject::Create() // apparently doesn't work! "Size of identifier does not match prototype"
{
}

Other than that, this is pretty useful and exciting stuff. Thanks for taking the time to look into it. :=

Well, I created a cleaned up branch for it:

https://github.com/gurok/ags/tree/331_new_user_struct (https://github.com/gurok/ags/tree/331_new_user_struct)

Just a minor tidy up and monkey_05_06, your example should now compile. Not sure if the way I've fixed the bug is correct though. Going to possibly revise it in the future.

It relates to forward declarations. They don't know the size of themselves. That's fine, but all pointer declarations should have a size of 4.

While testing, I made a pointer to a test struct with two ints and the size of its type was 8 (or 0 at the time of declaration). 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but not the size of the pointer. It looks like we need an if() statement to see whether it's a pointer somewhere and change its size accordingly. I'll have to investigate.

You should now be able to create an array of your managed struct too.

I haven't implemented constructors, but I'll be adding them after I fully investigate this pointer issue. And possibly clean up some other areas.

May you please make separate commits for changes in Engine and Compiler? Because they are, in fact, separate programs.
(I know, I am a great formalist)
That patch I made could work as a commit on its own. It will even bear my name on it :=.
(if something will go wrong everyone will know who is responsible :tongue:)

Quote from: Gurok on Wed 02/07/2014 13:48:56
While testing, I made a pointer to a test struct with two ints and the size of its type was 8. I believe this should be 4. 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but in all the cases I saw, it looked like pointers were always 4.

I think you are confusing the size of struct and size of "pointer" (managed handle)?

Quote from: Crimson Wizard on Wed 02/07/2014 13:56:00
May you please make separate commits for changes in Engine and Compiler? Because they are, in fact, separate programs.
That patch I made could work as a commit on its own. It will even bear my name on it :=.
(if something will go wrong everyone will know who is responsible :tongue:)

Quote from: Gurok on Wed 02/07/2014 13:48:56
While testing, I made a pointer to a test struct with two ints and the size of its type was 8. I believe this should be 4. 8 is correct for the size when calling SCMD_NEWUSEROBJECT, but in all the cases I saw, it looked like pointers were always 4.

I think you are confusing the size of struct and size of "pointer" (managed handle)?

Oh right, yes, I'll fix up the commits soon. Sorry. I would actually be happy if you made a branch and I sent you patches to fix things.

Yes, maybe you're right. I just had a look at some of the other managed types (Character *, Object *) and they seem to report their struct's size too.

Quote from: Gurok on Wed 02/07/2014 14:12:41I would actually be happy if you made a branch and I sent you patches to fix things.

You can make pull requests to separate feature branches too. Or, it is what you actually mean?
But this really does not matter who makes a branch.

Quote from: Gurok on Wed 02/07/2014 13:48:56monkey_05_06, your example should now compile.

It relates to forward declarations. They don't know the size of themselves. That's fine, but all pointer declarations should have a size of 4.

I can confirm that your fix does allow it to compile. The explanation also makes sense, as does the solution. :)

Quote from: Gurok on Wed 02/07/2014 13:48:56You should now be able to create an array of your managed struct too.

I can also confirm this is working, though it took me a second to realize that I'm now responsible for creating the objects in the array too (simple enough to handle with a "CreateArray" function). Now if only we could have dynamic arrays as struct members... (roll)

Quote from: Gurok on Wed 02/07/2014 13:48:56I haven't implemented constructors, but I'll be adding them after I fully investigate this pointer issue. And possibly clean up some other areas.

This will definitely be helpful as well. :)

Updated patch for the engine support of user objects:
http://www.mediafire.com/download/bo3d6c6y6a5hexw/0001-Engine-managed-user-script-object-support.patch

BTW, allows user objects of 0 bytes to 2 GB size. There's a reason why I used signed integer as "size" type (explained in comments).
This means "own" size of struct. You can allocate more size by putting pointers to other managed objects inside the first one.

I just wanted to make a small notice; it may not be really important for other developers at the moment, so just FYI.

After considering this for a while, I made a decision to not use the "develop" branch as a base for the future release, but instead start extracting commits by thematical groups to other branches, like develop-3.3.1.
Why: "develop" branch contains lots of various changes, some of them are ready, others still in "alpha" stage and require some extra work to make them finished; and these changes were made in random order, that makes it impossible to make partial merges (e.g. with 3.3.1). Also, there are even such changes that are not needed anymore, and would be reverted anyway. Some things made in haste and fixed for numerous times, etc.

This branch is a result of a very bad planning from my side. Also, back then I could not predict how far will 3.3.0 and 3.3.1 versions evolve.

I made a full list of commits in "develop" and grouped them thematically. I can already see which ones could be useful for 3.3.1: primarily cleaned up (refactored) code and some utility functions. Thus at least some of that code will get into real use at last.
The difference between develop and develop-3.3.1 (https://docs.google.com/document/d/1OiM9cp6Cp2_MgCKjgfMjIYizwtmLsmjzBW9lpcXlXHY/edit?usp=sharing)
Commits by group (https://docs.google.com/document/d/1ECsrZEuM_Dsc706SmVrj_qdsaFP1gW66FzeigUIqKvw/edit?usp=sharing)

I know that there's another branch based on "develop", the "multi_room_edit" by monkey_05_06, but its commits can be extracted same way when time is right (or simply rebased, since he practically was editing only one file). Same goes for any other work made on top of "develop" by anyone other (if there is some).

There's now a pull request for the managed object support:

https://github.com/adventuregamestudio/ags/pull/165 (https://github.com/adventuregamestudio/ags/pull/165)

I wasn't able to get constructors working in a satisfactory manner without making the code look like Frankenstein's monster. I will attempt this again in the future. I have reasoned that it's not crucial for 'version 1.0' of user-managed objects, and we have enough to test as it is. We can introduce constructors at a later date and enforce bracket notation (e.g. n = new MyStruct() ) only when a constructor is present in the struct.

Regarding the implementation of constructors, I welcome anyone else to try. To be done properly, I think it will need serious refactoring.

Quote from: Gurok on Sun 13/07/2014 06:05:47
I wasn't able to get constructors working in a satisfactory manner without making the code look like Frankenstein's monster.
<...>
Regarding the implementation of constructors, I welcome anyone else to try. To be done properly, I think it will need serious refactoring.

I +1 this. When I was testing monkey_05_06 addition that allows managed arrays in structs, I noticed that there's another piece of code that creates global/local arrays, it looked 98% the same, but was located in separate function.

Urgh... I just had a revelation that told me that user objects won't work :(.
Because they do not know how to remove reference count from managed objects inside them when they are disposed themselves.
I will check how common structs work, but I suspect this is done by compiler (when local or global struct is deallocated).

For dynamic arrays it's not a problem, because they store only one type, and know what it is exactly.

This problem is far more complex than anything else related to managed structs. I will need to think more about this.
E: The dumb way is to have a list of offsets for all managed handles inside struct. In any case this means that script interpreter must support some kind of "type description".

This may be a good time to port the compiler fully over to managed code (C#). I've actually started exploring that already, but I need to understand the compiler better to make a useful conversion. I've been going through and heavily commentating the script in a separate local branch. If anyone would find it useful I could share, once I'm finished documenting.

I really don't mean this as discouragement or criticism, but I wonder if all the energy put into hacking the scripting language might not be more usefully spent on other parts of the engine. The fact is that AGS Script isn't that unique, and we might be better off simply adopting a standard one with an existing compiler than having you spend so much effort trying to improve what we have. We're unlikely to be able to do better than off-the-shelf in this area, I think. We've already discussed alternatives, from Lua to AngelScript or Javascript (or perhaps UnityScript?) to Mono/C#. Personally I feel this is the path we should take, and that exploring the different alternatives is more useful in the long run than figuring out how to reimplement the wheel.

But again, I'm not the one doing the work, so take this for what it's worth.

@Snarky, that's the reason I, personally, don't really want to touch it much.
I'll see if the user objects can be made work without much hassle...

If AGScript is replaced by a Java-based language, I will stop contributing to AGS development.

I agree that replacing it with another language (AngelScript would probably be best) would be the best course of action but it's a significant thing to do.

Replacing it would be better in the long term because we get all the advantages of a popular, off-the-shelf library but it would take a lot of work.

Quote from: Crimson Wizard on Sun 13/07/2014 16:28:31
E: The dumb way is to have a list of offsets for all managed handles inside struct. In any case this means that script interpreter must support some kind of "type description".

Speaking of dumb ways... if you can't solve it, the half solution you proposed on GitHub seems reasonable to me. Disallow non-built-in managed struct pointers inside managed structs. We could then enable them at a later date when we've figured out how to manage them. I know it cripples managed structs, but there's already so much functionality provided by passing in and returning struct pointers. I'd hate to see it shelved. Crippled managed structs also don't do anything bad. They don't box us in for future development.

Quote from: monkey_05_06 on Sun 13/07/2014 18:52:08
If AGScript is replaced by a Java-based language, I will stop contributing to AGS development.

Hear, hear. I don't think anyone who contributes really wants that.

Regarding AGS script, I'm not in favour of replacing it for the time being. AGS script isn't just the language, it's the VM too. We aren't reinventing the wheel. We inherited a project that (for better or worse) reinvented it and we're uh... reinventing a few spokes. Ewww, terrible analogy. Point is that AGS script is 90% there.

^ I basically... Yeah, what Gurok said. ;)

Quote from: Gurok on Mon 14/07/2014 01:53:17
Speaking of dumb ways... if you can't solve it, the half solution you proposed on GitHub seems reasonable to me. Disallow non-built-in managed struct pointers inside managed structs. We could then enable them at a later date when we've figured out how to manage them. I know it cripples managed structs, but there's already so much functionality provided by passing in and returning struct pointers. I'd hate to see it shelved. Crippled managed structs also don't do anything bad. They don't box us in for future development.

Well, if you think that's proper; you then need to fix the compiler appropriately, and reopen/remake the pull request.

Quote from: Crimson Wizard on Mon 14/07/2014 07:08:26
Well, if you think that's proper; you then need to fix the compiler appropriately, and reopen/remake the pull request.

I just want to make sure I understand the problem correctly. Managed structs with user struct pointers are bad because the references aren't cleaned up recursively, but structs with pointers that come from the engine (e.g. Character, Object) should be fine as the engine cleans them up when appropriate. Correct? I need to know if I should lock down all pointers or just user ones. Never mind. I just read your GitHub note again. I believe I need to restrict them so that they can't include any pointers.

Quote from: Gurok on Mon 14/07/2014 07:21:05I just read your GitHub note again. I believe I need to restrict them so that they can't include any pointers.

BTW, we need to recheck if any of the existing managed structs contains pointers... if some do, then some alternate solution should be invented.
For instance, we may allow pointers in structs declared as "builtin".

Regarding universal solution. Here's a raw sketch:
1. "Type info" object is created for every basic type (int, float, pointer) and every user-declared managed struct. Type description tells object size and useful info. For the time being we need an array of offsets for pointer types in structs (letting engine know which pointers this object has).
2. When any object is created with new, compiler tells not the size of struct, but an ID of type info, letting object know which struct it represents.
3. We may even make dynamic arrays work the same way: make the "create object" command pass extra "number of elements" parameters. Type info is one of the basic types (int, float or pointer), so array will know how to deal with elements too.

This will require increasing "script data format" number (I recall there's one); the compiler must write the "type infos" chunk, and engine must know how to read it.
Don't know about compiler, but I don't think this should be terribly difficult for engine.

Quote from: Snarky on Sun 13/07/2014 18:33:05
I really don't mean this as discouragement or criticism, but I wonder if all the energy put into hacking the scripting language might not be more usefully spent on other parts of the engine. The fact is that AGS Script isn't that unique, and we might be better off simply adopting a standard one with an existing compiler than having you spend so much effort trying to improve what we have.

That strikes me as a very bad idea, as it would throw out backwards compatibility with all existing games and ongoing projects, as well as invalidate most of the skill that our community members have developed with using the scripting language.

The AGS scripting language works, and has worked well for over a decade, and we've got a database of nearly two thousand games to prove it. There's absolutely no good reason to replace it by some arbitrarily chosen "more popular" scripting language.

Quote from: Radiant on Tue 15/07/2014 14:17:04
There's absolutely no good reason to replace it by some arbitrarily chosen "more popular" scripting language.

Speed and upstream support seem like the most obvious ones to me.

What Calin said. There's also (depending on the choice of language):

• Improved documentation and more/better scripting tutorials "for free". Beyond very basic scripting, AGS doesn't really offer much help for learning, and many important features are not even clearly documented â€" at least in the most in obvious locations (for example, any time I need to export/import variables or declare struct members functions I have to go find an existing script that does it; neither is properly explained in the manual). Of course, our documentation could be improved, but that's just making more work: in addition to reinventing the wheel we also have to explain it!
• Better code debugging/analysis tools.
• More appeal to new users. It's all well and good to say that you've been using it for ten years and it works fine for you. But we also want to attract new developers, and a home-rolled scripting language is not exactly a selling point.
• Ability to use standard libraries and code samples.
• (Speculatively): Ease of porting. While AGS is clearly the bestest engine in the world, for various reasons some poor deluded sods occasionally decide that they'd rather use a different engine after all. (For example: Nelly Cootalot 2 in order to target more platforms.) Scripts written in a standard language could potentially be easier to port, particularly if the new engine use the same one (otherwise there are cross-compilers). This could be an argument for Javascript, which Unity3D supports a dialect of.
• As a consequence of this, using a standard language might make AGS more popular as a game prototyping tool.

At the same time, I agree that it's important to preserve as much of people's scripting expertise as possible, and make it as easy as possible to port ongoing projects (not to mention existing modules!), so I would favor a language with a syntax as similar as possible to AGS Script. That would probably be AngelScript or C# on Mono, although Javascript is also superficially similar. As to monkey's reaction, none of these options are Java-based.

Quote from: Calin Leafshade on Tue 15/07/2014 14:38:20
Speed and upstream support seem like the most obvious ones to me.

I've seen zero evidence that AGS has speed issues. In fact, I've done all kinds of crazy scripting within AGS (including writing first-person maze games and platformers) and based on this experience I'd suggest that AGS's speed is fine.

Quote from: Snarky on Tue 15/07/2014 17:05:27
What Calin said. There's also (depending on the choice of language):

The thing you're overlooking is that AGS's scripting language isn't some weird arbitrary custom design. Rather, AGS's language is, for the intent of learning it, pretty much identical to C++, one of the most commonly used languages in the world (granted, there are some C++ constructs that AGS doesn't support, but nothing that would be used by somebody learning how to program). This also means it's very close to C, C#, PHP, and JAVA; meaning that any novice programmer familiar with any of those can pick up AGS almost instantly, and can use tutorials and coding samples for any of these languages. By constrast, LUA is known to substantially less people.

As far as I've seen, AGS ports just fine to Mac, Linux, and Android already, so I'm not sure what else you'd want to port it to. And I'm not sure why anyone would want to use AGS as a prototyping tool; it's an engine for creating games, not a prototyping tool.

Now I grant that it would be nice to use better debugging tools and be able to import standard libraries, but converting AGS to some other language won't actually accomplish that. Rather, I'd be curious to see what specific examples of debugging and libraries people would need. I'm willing to bet that simply creating these would be way easier than swapping out AGS's scripting language to something else.

Overall, you're suggesting a huge sweeping change, requiring huge time investments with clear and obvious drawbacks, for only hypothetical benefits. That's not a good tradeoff.

Quote from: Radiant on Tue 15/07/2014 20:46:05
I've seen zero evidence that AGS has speed issues.

The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.

Quote from: Calin Leafshade on Tue 15/07/2014 21:51:14
The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.

Ah yes, that same core engine team that states above that they'll quit if AGS changes to a different scripting language. Sorry, I don't see how you have much of an argument here; hundreds of game developers and 100000s of game players have no issue with AGS's speed.

Quote from: Radiant on Tue 15/07/2014 22:11:05

Quote from: Calin Leafshade on Tue 15/07/2014 21:51:14
The core engine dev team even admit there are speed issues. The compiler has absolutely no optimization at all which is especially noticeable in tight loops.

Ah yes, that same core engine team that states above that they'll quit if AGS changes to a different scripting language.

Now, wait a minute... monkey_05_06 is not a "core engine team", he is a single person with his own opinion :). Also, I do not recall he ever mentioned slowness of AGS script.
I had though, and my opinion is different (I am not saying "opposite" btw). Well, at least I would not quit just because of different scripting language. I guess monkey has his own long history with AGS Script, so he is sensitive when it comes to this topic.

I was specifically talking about CW, yes.

Reference:

Quote from: Crimson Wizard on Wed 27/11/2013 23:37:05

Quote from: Calin Leafshade on Wed 27/11/2013 23:21:56
The AGS compiler, AFAIK, has no optimisation and uses no advanced CPU instructions.

Unfortunately, that's true. It produces very formal sequence of instructions, mimicing how real x86 processor (IIRC) works: putting values to registers, getting them back, calculating, putting result to register, getting it back once again for other use, etc, etc., and every action is processed separately. I think it does at least about 3-5 things more than needed (http://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0) per each primitive operation.

This "formal sequence" makes things like loops very very slow.

I have benchmarked this and I reckon the Lua plugin, which has an extra layer of abstraction to deal with, is about 5-10 times faster depending on what you're doing (loops mainly).

Also this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0

So when talking specifically about the speed of AGS script, it is you that has no argument here, my friend.

When it comes to replacing AGS script, I am broadly for it but I understand that it's simply unlikely to happen due to the time involved.

Quote from: Radiant on Tue 15/07/2014 20:46:05

Quote from: Calin Leafshade on Tue 15/07/2014 14:38:20
Speed and upstream support seem like the most obvious ones to me.

I've seen zero evidence that AGS has speed issues. In fact, I've done all kinds of crazy scripting within AGS (including writing first-person maze games and platformers) and based on this experience I'd suggest that AGS's speed is fine.

AGS clearly has speed issues. Whether the scripting language is the real bottleneck in most practical situations is admittedly more of an open question.

QuoteThe thing you're overlooking is that AGS's scripting language isn't some weird arbitrary custom design. Rather, AGS's language is, for the intent of learning it, pretty much identical to C++, one of the most commonly used languages in the world (granted, there are some C++ constructs that AGS doesn't support, but nothing that would be used by somebody learning how to program).

Like for loops? (At least until the upcoming version.) Switch/case statements? Classes? And on the other hand, how many "pObj->method()" expressions do you see in AGS Script? Yes, AGS Script roughly resembles C++, but there are plenty of differences, and anyone trying to use a C++ tutorial to learn AGS Script isn't going to get past "Hello World!"

You can make an argument for AGS Script being less intimidating to newbies than Lua (though it is very popular for game development), but that argument doesn't really stand up against the other alternatives mentioned.

QuoteAs far as I've seen, AGS ports just fine to Mac, Linux, and Android already, so I'm not sure what else you'd want to port it to.

http://unity3d.com/unity/multiplatform
The point wasn't about AGS supporting more platforms, but making it easier to move game logic between AGS game builds and builds in other engines.

QuoteAnd I'm not sure why anyone would want to use AGS as a prototyping tool; it's an engine for creating games, not a prototyping tool.

A game prototyping tool. I can see ways in which it would come in handy, but it's a pretty speculative use-case, so let's not argue about it.

QuoteNow I grant that it would be nice to use better debugging tools and be able to import standard libraries, but converting AGS to some other language won't actually accomplish that.

Well, switching to a standard language would allow us to use off-the-shelf tools and libraries, so it would accomplish that.

QuoteRather, I'd be curious to see what specific examples of debugging and libraries people would need. I'm willing to bet that simply creating these would be way easier than swapping out AGS's scripting language to something else.

Perhaps the handful of specific features or libraries I could mention off the top of my head would be easier to reimplement (for example, let's start off with a library for handling database connections, proper XML parsing, graph layout, a comprehensive physics engine, a more advanced parser, an agent-based AI library, and better gesture/drawing recognition...), but that building every feature and library that would be useful for an adventure game would be quicker than slotting in a different scripting language I find highly doubtful. That's sort of the crux of the argument: While switching to a standard language may be more work up front, trying to compete with popular, well-supported languages on features, tools, libraries and performance is an insurmountable task, and no matter how much work people put into hacking it, it's still not going to be as good. (No offense to the engine devs, but without a large, expert, dedicated team focusing solely on the scripting language, it's just not.)

The same way AGS shouldn't rely on its own home-brewed graphics library or audio library, it really shouldn't have its own home-brewed scripting language. The only reason it does is legacy, and while it will no doubt be with us for quite a while still, it would be better to start the planning for its replacement earlier rather than later, in my opinion.

Quote from: Calin Leafshade on Tue 15/07/2014 22:52:44
I have benchmarked this and I reckon the Lua plugin, which has an extra layer of abstraction to deal with, is about 5-10 times faster depending on what you're doing (loops mainly).

That's really not the point. Just because certain things can theoretically be faster doesn't mean that AGS has speed issues. If you want pure speed, go program in assembly code. The question is whether AGS is fast enough for what it's meant to do (i.e. run adventure games, and possibly other games) and the answer is a resounding "yes".

Look, if you're going to make a case for fundamentally rebuilding AGS, start with practical arguments. As in, find some people who've been working on a large scale adventure game, and ask them what their actual issues were, and if they managed to create a game anyway despite the lack of a "switch" command. Ask if any of their players found that their low-resolution games were running inordinately slow on contemporary computers. Ask whether they found AGS hard to learn, and if they'd have had an easier time if its script had been based upon Turbo Pascal. Get a view of the real issues, not of hypotheticals.

I've mentioned this once: if there were a plugin interface for script interpreter / compiler, you could use any language in AGS.
Interpreters mainly do their internal job, their only connection to engine is registered engine API.

Yes, that would be best. Thats essentially what the Lua plugin does. Most of the necessary API functions are there (except for registering engine events).

I have a question regarding the issue of pointer members of managed structs. CW has said that this can't (simply) be made to work. I'm trying to understand why. The engine already has reference counting and garbage collection for the built-in managed types, including DynamicSprites and dynamic arrays. These pointers can be included as members of user structs, which only exist as one instance, but are still cleaned up by the garbage collector. There are no known issues with pointer members of user structs. So where is the discrepancy when it comes to managed (dynamically allocated) user structs? Shouldn't the reference counts for pointer members still be updated, and the relevant objects freed if their reference counts reach zero? :-\

Quote from: monkey_05_06 on Sun 20/07/2014 04:08:31
I'm trying to understand why. The engine already has reference counting and garbage collection for the built-in managed types, including DynamicSprites and dynamic arrays. These pointers can be included as members of user structs, which only exist as one instance, but are still cleaned up by the garbage collector. There are no known issues with pointer members of user structs. So where is the discrepancy when it comes to managed (dynamically allocated) user structs? Shouldn't the reference counts for pointer members still be updated, and the relevant objects freed if their reference counts reach zero? :-

The problem is in changing reference counter.
The difference between two struct types - the ones "statically" and "dynamically" created - is that those statically created are "managed" by compiler. Compiler knows when to destroy them, and what to do with their data. IIRC when a struct instance is deallocated (deleted from local stack or global data), all reference's counts are decreased, but this is done by compiler (it writes certain script commands), because compiler knows the structure of data, it knows WHAT to decrease.
Dynamic arrays "know" that too, because they contain only one type of data (and specifically aware if this is pointers).
For dynamic user object implementation in the engine, there's no "structure", there's only a data chunk of given size. In order to know if this data contains references and where they are located in this chunk we need some kind of "type description".
Basically, this is it.

Here I explained how this may be done (for example):
http://www.adventuregamestudio.co.uk/forums/index.php?topic=49969.msg636492665

EDIT: Another possible way is to invent some kind of automatically generated destructor (created by compiler), which will do same work, but as a part of byte-code.
The compiler does not know WHEN to dispose object, so this will require engine to run a generated byte code by given address, or something.

EDIT2: I support the first solution. Furthermore, I'd even support changing how compiler/engine manage stack and global data, so that compiler would just tell engine which variable to dispose, and engine knew how to do that, instead of emulating x86 "pop stack" operations... (but this is another topic).

I'm still a little bit confused. It seems that in order for structs to even work, they would have to know the relevant types and offsets of the members, but you're saying that's not the case? >:(

The point is that they don't know at runtime.

Quote from: Calin Leafshade on Mon 21/07/2014 07:37:56
The point is that they don't know at runtime.

Yes,... this... basically is what I tried to explain with 20 lines of text :).

Since it is engine that is responsible for creation and deletion of dynamic objects, it needs to have enough info about their contents. In regards to custom user structs - currently it does not have enough.

Quote from: Calin Leafshade on Mon 21/07/2014 07:37:56
The point is that they don't know at runtime.

Oh...duh. (roll)

So since the compiled program basically just deals with chunks of raw memory, and the members are then offsets from a parent address, essentially we need an additional step to say, "Before you free up this memory, derefence this offset and free up its memory too," right?

Yes, you need a way to crawl the reference tree and free all child objects (and their children).

Essentially what CW is talking about is the beginnings of a form of type reflection which would be great, especially if exposed to scripts somehow :">

Quote from: Calin Leafshade on Tue 22/07/2014 17:26:39
Essentially what CW is talking about is the beginnings of a form of type reflection which would be great, especially if exposed to scripts somehow :">

^_^

I will probably be merging custom display resolutions code into 3.3.1 in a short while, and as an alternative approach I am considering removing "winsetup" from engine code completely and replacing it with stand-alone cross-platform program that will run on all desktop systems (Windows and Linux at least).

This time I'd like to use the ideas by Snarky and others about how to make a useful GUI to setup custom resolution (without the dreary "slider" thing for window scaling I made in the "experimental CR" build).

I'll be frank and honest, telling that I don't really want to spend much time and effort on writing an uber customizable setup with skins etc at this time (it has been said several times that game devs can make their favorite setup program themselves :tongue:).
I am leaning towards FLTK (http://www.fltk.org/) for portable gui and SimpleINI library (https://github.com/brofield/simpleini) for portable INI reader/writer.

The FLTK is not the best-looking GUI, but it is very simple and has minimum dependencies. In the end, it may be used as an example for making other setup programs.

I would like to know if anyone else is/was working on "portable winsetup" meanwhile. Maybe there's already such program? I recall someone expressed a will to make one, but I never heard if he finished it.
Thing is that as soon as I get free resolutions code into AGS, the old winsetup will become practically useless and will need a rewrite anyway, so I would not want to wait too long.


-----------------------------------------------

On a second, minor, issue, I am starting to think that this may be not 3.3.1 but 3.4.0 release, considering what breaking new features are and will be added into it (user structs & free resolutions alone). I think I chose slightly incorrect way to continue development again. I guess we should have made two branches - for 3.3.1 and 3.4.0 and generally work in 3.4.0, but merge some lesser changes and fixes into 3.3.1 (merging 3.3.1 into 3.4.0 periodically), or something like that.
But this may be difficult to do without clear roadmap (which I don't have).

Would it not be better to leave winsetup in for legacy purposes and instead, implement an in-engine solution?

Currently the engine has in-engine solutions for save, load and quit dialogs. Why not gfx settings?

The advantage of this is that it easily allows users to override the functionality and you don't have to maintain any GUI lib.

You could also consider Phoenix (http://byuu.org/programming/phoenix/) as a GUI toolkit. It's simple and uses the native widgets on each platform. Don't know how it compares to FLTK but I know that byuu writes very clean code.

Quote from: Calin Leafshade on Wed 06/08/2014 15:39:00
Would it not be better to leave winsetup in for legacy purposes and instead, implement an in-engine solution?

Because
a) There still may be need to set up options before launching the game. Some settings may cause game simply not start up, or crash - in exceptional cases, etc.
b) Implementing in-engine controls will require more time to design and implement the customizeable system. Also, at the time being I cannot predict how well the AGS will react to changing these parameters during the game.
c) At this moment I can't tell how much more will I work on AGS, therefore I am trying to stick to things that I know will work.

Also, what are "legacy reasons" to leave winsetup, when it will no longer will setup the program correctly, due to changes in how config works?

Quote from: Calin Leafshade on Wed 06/08/2014 15:39:00
The advantage of this is that it easily allows users to override the functionality and you don't have to maintain any GUI lib.

I am not going to maintain any lib. I want to write a small program that uses existing lib.

With regards to point B, AGS already has an inbuilt gui control system which is used by the aforementioned save, load and quit dialogue boxes. And the system would not need to be customizable just like the save/load dialogues arent. They can just be ignored and alternative systems implemented by the user.

Your other points are fair.

Also I agree that native widgets are better.
Another option is the Wx set which uses native widgets.

Of course, the in-engine settings may be added later, after it is investigated how well will they work.
Right now I want just to keep existing setup updated.

EDIT: wxWidgets have config file support too:
http://docs.wxwidgets.org/trunk/classwx_file_config.html
I understand it so that FLTK does not use native controls at all.

Quote from: Crimson Wizard on Wed 06/08/2014 15:27:08
I will probably be merging custom display resolutions code into 3.3.1 in a short while, and as an alternative approach I am considering removing "winsetup" from engine code completely and replacing it with stand-alone cross-platform program that will run on all desktop systems (Windows and Linux at least).

I applaud this idea and wholeheartedly support it!

but... will it still be WINsetup on linux systems? (wtf)

linsetup obviously.

Quote from: Calin Leafshade on Wed 06/08/2014 19:23:17
linsetup obviously.

Mostly known as $ ./configure
$ make
$ make install  :P
At Linux, you rarely find real setup programs like you do at Windows. One simply uses the standard development tools for building and installing the program.
Note that "installing" is mostly just copying files, there is no registry thingie that needs to be dealt with. Uninstall is just remove all copied files. You can install at a central place like /usr or /usr/local (by the superuser, to make it available for all users of the system), or inside a user home directory (for a personal installed copy).

The above command sequence configure/make/make install is quite normal for an install from source. Most Linux users however don't do that. Instead, Linux distributions normally build binary versions of all programs from the source code. They package the result in a .rpm or .deb file, which are distributed to all users with auto-magic updates etc. Users have package manager tools like "yum" (Red hat/Fedora) or "apt-get" (Debian/Ubuntu). There are also GUI versions of those programs. One can just select the package to install, and it will download the .rpm (or .deb), with all its dependencies, and install it.

Umm, Alberth, we were speaking about configuring the game (graphics mode, sound, other options, like language), not the installation on disk.

 :-[

Oops, sorry

Preliminary work: https://github.com/ivan-mogilko/ags-refactoring/tree/feature-free-resolutions
Will make a formal pull request after I test few things more.

TODO:
1) new setup (may be a separate pull request);
2) backward-compatible fix for rooms of smaller size than game (strangely, were supported before AGS 3.*).

ALSO:
3) add custom resolutions (should be simple, just apply couple of existing patches), probably will be separate pull request, because it is technically not related.

RELATED (work for undetermined future):
4) fully working OpenGL renderer
5) make all gfx filters work in a common way (scale from one rect into another), and drivers perform final scaling if required. Currently software filters do both operations, while Direct3D filters don't do anything except for setting up some render parameters (real OpenGL filters do not exist).


... 6) maybe make a small adventure game. It's been a while since I tried. :tongue:

I need some feedback on this:

https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_runtime_type_information?expand=1

Is it correct?
Is this enough information at runtime?
Can we build upon this to free relevant pointers when managed user objects are deregistered? (I don't know how to do this bit.)

The runtime type information currently presented is:
- total size of the object's type
- an array of offsets for any pointers to managed non-builtin objects contained within

Offsets tell you where the pointer is relative to the base address of the object. e.g. 4 -> pointer is at baseaddr+4

The file format version for scripts was bumped earlier in the 3.3.1 commits, so compatibility-wise the new chunk of info in script files should be fine.

I think this is a small amount of double handling. Is there an argument for dumping the symbol table (and ALL flags about objects) into each script and reading it back? I think not because with the structure of the symbol table, this would mean a long scan of all symbols to get info about the pointers inside a struct.

Sorry if this doesn't make sense. I was up all night trying to work out how best to do this. If this isn't right, it's at least a start.

Quote from: Gurok on Sun 24/08/2014 07:50:00
https://github.com/gurok/ags/compare/adventuregamestudio:develop-3.3.1...331_runtime_type_information?expand=1

This is very nice, I am going to check this out today.

Quote from: Gurok on Sun 24/08/2014 07:50:00
The file format version for scripts was bumped earlier in the 3.3.1 commits, so compatibility-wise the new chunk of info in script files should be fine.

Just being curious, why was it bumped? I probably missed this.

Quote from: Gurok on Sun 24/08/2014 07:50:00
I think this is a small amount of double handling. Is there an argument for dumping the symbol table (and ALL flags about objects) into each script and reading it back? I think not because with the structure of the symbol table, this would mean a long scan of all symbols to get info about the pointers inside a struct.

Umm, I might have failed english or don't know something :-\. Can you elaborate what you mean?
Nevermind, I think I got this.

The issues I found:

1. RTTI should not be stored in Script objects, but in a global struct, or inside a global object. By "global" I mean not necessarily literally 'global' in C language, but the one persistent and accessible all the program time.
Why: the managed object must keep the reference to Type, - either a pointer, or numeric Id, - all the time until its deallocation. If it is a pointer - we can't tell if the script we took this reference from will be available when the managed object is destroyed. If it is a numeric id - the managed object class does not have any reference to current (or any) Script (and should not have, because its illogical), therefore it won't know where to take type info from.

Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?) E: I found it's not :(. I see that this will be more complex to do.

I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.

1b. You must not change how existing script commands and their arguments work, i.e. SCMD_NEWARRAY, because thus you will break compatibility with older scripts.

You may only do the compiler / serialization part. I can take care of the engine part after the compiler will be saving proper data.

2. Maybe we should start using std::vectors for expanding arrays, otherwise we will have to write "expand" function for every new type/array we put into program.
We are moving towards converting all the code to C++ anyway.

3. I have a thought that maybe we should allow to call "new" on any struct, even ones without "managed" keyword, because there's really no difference. What makes it managed is whether it is created on stack/global data or with "new" keyword. I would like to hear what others think about this.


EDIT: I investigated a bit more, and I see that the sym table actually stores only symbols from currently compiled module + the headers it includes. Something has to be done with this.
The problem is, that the object may be allocated in a room script, and then assigned to global variable. If we assign an Id of a type stored in the RTTI table of a room script, then we may loose this info after room was changed.
This means that the best way to achieve what we need is to keep a global sym table.

EDIT2: There's still a chance that, since module headers are always included in one order, the ids of types declared in upper headers will remain the same... meaning it can work, for starters.
Still this implementation would require managed object to lookup the "current script" for type info when it is about to deallocate, which is not good.

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38
The issues I found:

1. RTTI should not be stored in Script objects, but in a global struct, or inside a global object. By "global" I mean not necessarily literally 'global' in C language, but the one persistent and accessible all the program time.
Why: the managed object must keep the reference to Type, - either a pointer, or numeric Id, - all the time until its deallocation. If it is a pointer - we can't tell if the script we took this reference from will be available when the managed object is destroyed. If it is a numeric id - the managed object class does not have any reference to current (or any) Script (and should not have, because its illogical), therefore it won't know where to take type info from.

This is really hard, but I'll try. Copying the type information to the managed object when it's constructed would also solve the problem.

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38

Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.

This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38

1b. You must not change how existing script commands and their arguments work, i.e. SCMD_NEWARRAY, because thus you will break compatibility with older scripts.

Oops. I take it I screwed up with the changes to read the size of the object. :-[ I'll fix that. Where/how should we embed the ID of a type in the compiled script then?

EDIT: My feeling was that we could pass the ID instead of the size to SCMD_NEWARRAY and SCMD_NEWUSEROBJECT, but use the file format to determine how it behaves (if < 90, treat it as size otherwise treat it as an ID)

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38

You may only do the compiler / serialization part. I can take care of the engine part after the compiler will be saving proper data.

2. Maybe we should start using std::vectors for expanding arrays, otherwise we will have to write "expand" function for every new type/array we put into program.
We are moving towards converting all the code to C++ anyway.

I can use those. No problem.

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38

3. I have a thought that maybe we should allow to call "new" on any struct, even ones without "managed" keyword, because there's really no difference. What makes it managed is whether it is created on stack/global data or with "new" keyword. I would like to hear what others think about this.

Ummm, that might get messy when people wonder why they can't return a struct created on the stack. Or wonder how to convert from stack variable -> heap variable. I kind of like the object management system the way it is. It's clunky, but it alleviates potential problem areas.

Quote from: Gurok on Sun 24/08/2014 14:04:32
Copying the type information to the managed object when it's constructed would also solve the problem.

That would, but that's a clumsy solution. It's like copying virtual table to every instance of a class instead of referencing one via pointer.

Quote from: Gurok on Sun 24/08/2014 14:04:32

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38
Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.

This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.

No, no, you seem to misunderstand what I mean. The script_rtti.dat will be inside game package, as well as all the other files.
Every script is a separate file too, and deleting them would screw the game anyway.
Game author would not need to worry at all, because this file will be added to final package automatically.
"Game data version" only refers to main game data inside the game package (ac2game.dta) - the one that describes the game generally.

EDIT:

Quote from: Gurok on Sun 24/08/2014 14:04:32
EDIT: My feeling was that we could pass the ID instead of the size to SCMD_NEWARRAY and SCMD_NEWUSEROBJECT, but use the file format to determine how it behaves (if < 90, treat it as size otherwise treat it as an ID)

That's possible, but I was thinking that in the future we won't need to use SCMD_NEWARRAY at all, SCMD_NEWUSEROBJECT could take care of arrays too (with some more info maybe). In such case SCMD_NEWARRAY will be used only for older scripts.

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38

Quote from: Gurok on Sun 24/08/2014 14:04:32

Quote from: Crimson Wizard on Sun 24/08/2014 13:41:38
Furthermore, the RTTI should probably be written to separate file in game package. It should include all types from all scripts (I guess this is what it does now?).
I suggest to introduce a new file to the game package, for example "script_rtti.dat", which would contain RTTI info from sym table in a simple format, e.g.:
- RTTI file signature ("AGS_SCRIPT_RTTI")
- RTTI format version (1?)
- the data
You would not need to increase game data version, because this is a separate file. Engine should just check whether it exists. If it doesn't, then scripts will work in "backwards-compatibility" mode, not allowing managed user objects, etc.

This feels a bit wrong to me, only because a game author would need to take this into account. e.g. He/she might need an alternate object management system just in case script_rtti.dat is deleted. I would prefer that we incorporate it into the main output file or add a flag when managed user objects are used so that the resultant game won't start without the script_rtti.dat file present.

No, no, you seem to misunderstand what I mean. The script_rtti.dat will be inside game package, as well as all the other files.
Every script is a separate file too, and deleting them would screw the game anyway.
Game author would not need to worry at all, because this file will be added to final package automatically.
"Game data version" only refers to main game data inside the game package (ac2game.dta) - the one that describes the game generally.

Okay, let me try building a global table instead and get a commit up when I think it's ready for review again. I have a better idea of what to do now.

I don't know all the details about how Sym Table is composed, but I can see it uses names as id. I guess you may need to add script name to type name, in case user declared two types with same names in two room scripts. Just a thought.

EDIT: I was thinking about this more... that might be actually not easy to work with global RTTI table, because the Editor does not recompile all scripts every time, neither keeps them in memory. Some idea is needed here.
One of the possible solutions is to keep RTTI tables in every script as you do now, but with type names (string ids). Engine might have a map of types (with string as a key) and add types to global table as scripts are loaded.
When user object is created, engine will map script own type index into global string key.
Not the perfect solution, but may work for starters.

I was just about to come in here and post about that, CW :D

We can't really do a global table because each room is a separate compilation unit. We could perhaps serialise the script-specific table as we are now, but read it back when producing final output (regardless of whether the room was compiled) in order to create a global table. Seems cumbersome and difficult to do. I much prefer the suggestion you made of using a string at runtime. Perhaps the struct name with a script name as a qualifier, e.g. GlobalScript::Weapon

One thing I'm not clear on. To make my proof of concept work, I substituted a type ID for the "size" parameter in SCMD_NEWUSEROBJECT. This allowed SCMD_NEWUSEROBJECT to correctly identify the type of the object it was creating. How do you propose we pass this information to SCMD_NEWUSEROBJECT when the primary type identifier is a string?

EDIT: Regarding my last question, would you be happy if we:
- Use the script-specific type ID only when an object is created
- At that point, create an entry in the global type table using the true name of the type (e.g. GlobalScript::Weapon) if it doesn't exist
- Have the destructor use the global type table to find the type info when deleting the object?
Because I think that could work. I hope that's what you were getting at and I'm not completely off track.

EDIT:

Quote from: Crimson Wizard on Sun 24/08/2014 11:57:24

Quote from: Gurok on Sun 24/08/2014 07:50:00
The file format version for scripts was bumped earlier in the 3.3.1 commits, so compatibility-wise the new chunk of info in script files should be fine.

Just being curious, why was it bumped? I probably missed this.

I think I bumped it when new commands (do, for, break, continue) were added. In retrospect, it was probably not a file format change, but it would have been weird to have an earlier interpreter open it.

Also, I need to look into how exported types are loaded when a script is compiled. It's my understanding that the script compiler loads all previously exported symbols and then compiles the script (making it possible for a type ID to refer to types declared in previous modules). I'm not sure if my new "rtype" field gets populated at that time, however.

Quote from: Gurok on Mon 25/08/2014 02:28:31
We can't really do a global table because each room is a separate compilation unit. We could perhaps serialise the script-specific table as we are now, but read it back when producing final output (regardless of whether the room was compiled) in order to create a global table. Seems cumbersome and difficult to do.

There's an alternative to keep RTTI in a project folder all the time (same as room CRMs are kept in project), and read it in memory before any compilation.
Update it when a script is compiled. Since type ids have script module tag in them, program will know which types to update / remove (if module was removed). Then save it back to file.

Quote from: Gurok on Mon 25/08/2014 02:28:31
One thing I'm not clear on. To make my proof of concept work, I substituted a type ID for the "size" parameter in SCMD_NEWUSEROBJECT. This allowed SCMD_NEWUSEROBJECT to correctly identify the type of the object it was creating. How do you propose we pass this information to SCMD_NEWUSEROBJECT when the primary type identifier is a string?

What I suggest is to use solution consistent with function binding. Function binding works this way: every script has a list of functions it uses, and to call them it puts their local index in the byte code. Engine uses this local index to look up in the local table and find function name, under which it is registered in global table.
Similarily, regardless of whether we have a global RTTI, or a table in every script module, the numeric id will mean the index in local types array. This will be array of either full type descriptions, or only their names.
In any case - use numeric id to acquire string id from module's array of types, then this string is used further to find persistent type description from global table.
If we keep type infos in the module, the global table must be filled on script load, to get the types prepared.

Quote from: Gurok on Mon 25/08/2014 02:28:31
EDIT: Regarding my last question, would you be happy if we:
- Use the script-specific type ID only when an object is created

You mean - does not use it for arrays?
I guess we would actually need them for arrays too, because arrays may store user objects. This is not allowed now, but if we make this, it may be.
However, my idea was to merge SCMD_NEWUSEROBJECT and SCMD_NEWARRAY at some point in the future. The SCMD_NEWUSEROBJECT could take two arguments: a type id, and number of elements. If second arg is > 1, then array is created.
In such case SCMD_NEWARRAY will remain for backwards-compatibility only.
The problem here is that we need to somehow distinct array of pointers to struct and array of structs. I guess this is where "managed" flag may come of use. But I'd rather think a bit more about this.

@Gurok and others, unfortunately I was pretty busy lately, and will be even more busy in next 5-10 days on my job (we are having deadlines here too :)), so if you post new variant of RTTI feature I may not be responding for some time.

Telling this just in case.

Quote from: Crimson Wizard on Wed 27/08/2014 20:30:39
@Gurok and others, unfortunately I was pretty busy lately, and will be even more busy in next 5-10 days on my job (we are having deadlines here too :)), so if you post new variant of RTTI feature I may not be responding for some time.

Telling this just in case.

Not a problem, CW. We are all busy with other commitments and jobs. I find it hard to squeeze in time too.

I have a proposal to rename our development branch to 3.4.0 now, because it has bigger features now (improvements to scripts mostly), and probably will have more, while X.X.N+ versions are meant for very minor improvements and fixes. I was supposed to release a new update to 3.3.0 containing restored letterboxed mode and few other hot-fixes, now I am thinking about actually calling it 3.3.1, and using 3.3.2 number if more hotfixes are required.
(I should have probably done this much earlier).

Are there any objections to this? If not I'll just create a new "develop-3.4.0" branch right where "develop-3.3.1" now is, and the latter may be safely deleted a bit later when everyone gets updated.

Quote from: Crimson Wizard on Mon 08/09/2014 22:54:19
I have a proposal to rename our development branch to 3.4.0 now, because it has bigger features now (improvements to scripts mostly), and probably will have more, while X.X.N+ versions are meant for very minor improvements and fixes. I was supposed to release a new update to 3.3.0 containing restored letterboxed mode and few other hot-fixes, now I am thinking about actually calling it 3.3.1, and using 3.3.2 number if more hotfixes are required.
(I should have probably done this much earlier).

Are there any objections to this? If not I'll just create a new "develop-3.4.0" branch right where "develop-3.3.1" now is, and the latter may be safely deleted a bit later when everyone gets updated.

No objections from me! Makes a lot more sense than the 3.3.0 Hotfix N approach.

Crimson Wizard (et al),

Firstly, in the development branch, I've found a problem with the most recent commits for D3D9 front buffer / back buffer stuff. I have a game project with sprite 0 set to:

http://i.imgur.com/ADz2Dtm.png (http://i.imgur.com/ADz2Dtm.png) (don't ask why)

The editor fails to load it, complaining that it can't find sprite 0. If I try to run the game data file with the most recent engine, I get a similar error on startup. This doesn't occur when I go back to a commit before 67de2af. Haven't fully investigated it yet. (I'm not asking you to fix it! Just documenting it!)


Secondly, my current large project has too many scripts (according to AGS):

(http://i.imgur.com/9ZPRjcP.png)

I have exceeded MAX_SCRIPT_MODULES. I couldn't believe the error when I saw it. I don't think I'm doing anything wrong. I've got 1 module per extension (e.g. Mouse, Character), and a few extra modules for custom things in "Library", 1 module for each inventory item, global object, character and GUI. Okay, so I'm a bit of a neat freak, but is that an unreasonable way to organise things? (Might be the wrong forum.)

I checked your earlier 3.4.0 branch and there's no mention of MAX_SCRIPT_MODULES as a limit. I think increasing this from 50 to 200 would be sufficient for my needs. We could look at removing the limit in the future.
I monitored memory usage. With max=50, my RAM usage is 30.7MB. With max=200, my RAM usage is 30.8MB. I don't think upping the limit is a huge concern.

Edit: If my request isn't unreasonable, here's a pull request for that script module limit: https://github.com/adventuregamestudio/ags/pull/179

It is better to remove the static limit at all, if it is possible to do without much hassle.
The biggest problem I met were room areas limit, that could not be safely removed without completely changing savegame format.

Regarding sprite error, I can't reproduce it. Only reason I can think of is the mistake introduced in commit 67de2af and fixed with next commit 6fa6e4e.

I'm sorry, CW. I misdiagnosed the sprite cache problem earlier. Here's a pull request to fix the problem that prevented my game project from loading: https://github.com/adventuregamestudio/ags/pull/181

Edit: I can PM you my game project on request, but it's pretty big!

Edit 2: I just submitted the pull request for removing the 50 script limit. Ohhhhh yeah! https://www.youtube.com/watch?v=oKnwHAGXvlE

Ok, I will make a final check tomorrow. Today I am just too sleepy :tongue:.

Quote from: Crimson Wizard on Mon 08/09/2014 22:54:19
I have a proposal to rename our development branch to 3.4.0 now, because it has bigger features now (improvements to scripts mostly), and probably will have more, while X.X.N+ versions are meant for very minor improvements and fixes. I was supposed to release a new update to 3.3.0 containing restored letterboxed mode and few other hot-fixes, now I am thinking about actually calling it 3.3.1, and using 3.3.2 number if more hotfixes are required.
(I should have probably done this much earlier).

I don't like these +hotfix version numbers. Why don't you increase the third number for every minor release? It's not like there are not enought numbers, after 3.3.9 there's still 3.3.10 and people don't really care if the changes are minor or very minor. Having a release hotfix-2, then update-1 and then hotfix-3 means the versions cannot be sorted. That makes every Linux package maintainer crazy and also other people won't know if update-1 or hotfix-3 is higher.

Quote from: BigMc on Fri 19/09/2014 18:30:07
I don't like these +hotfix version numbers. Why don't you increase the third number for every minor release? It's not like there are not enought numbers, after 3.3.9 there's still 3.3.10 and people don't really care if the changes are minor or very minor. Having a release hotfix-2, then update-1 and then hotfix-3 means the versions cannot be sorted. That makes every Linux package maintainer crazy and also other people won't know if update-1 or hotfix-3 is higher.

This is true, I just got carried away with this. Sometimes I am getting fixated on using some "scheme" and cannot leave it.
And people around seem too shy to make me stop :tongue:.
I will call next hotfix 3.3.1, and put an explanation in the topic so that people know that it is not Gurok's 3.3.1, but a further update of 3.3.0.

And while we're at it... Since you are releasing preview binary releases (alpha,beta,rc..), I think it would be a good idea to give them also proper version numbers. The approach that is most compatible with sortability of versions is to give odd numbers to development versions and even numbers to stable releases, e.g. call the development branch now 3.5 and let that turn into the stable release 3.6. This approach is for example used by Allegro and the Linux kernel.

Quote from: BigMc on Fri 19/09/2014 19:30:11
And while we're at it... Since you are releasing preview binary releases (alpha,beta,rc..), I think it would be a good idea to give them also proper version numbers. The approach that is most compatible with sortability of versions is to give odd numbers to development versions and even numbers to stable releases, e.g. call the development branch now 3.5 and let that turn into the stable release 3.6. This approach is for example used by Allegro and the Linux kernel.

Hmm, we are doing this, just changing the last (fourth) build number before every update (using odd numbers for development branch). Is not that enough?
I am afraid that unlike developers most common users will be confused if main numbers will be jumping between release versions, will look for intermediate versions etc.

Look for example at the Allegro homepage: http://alleg.sourceforge.net/
It's all pretty clear isn't it?

I think most users get AGS from the homepage where only stable releases are found or not?

Quote from: BigMc on Fri 19/09/2014 20:01:53
Look for example at the Allegro homepage: http://alleg.sourceforge.net/
It's all pretty clear isn't it?

Not sure... maybe I do not get something?
Don't we have same thing know, there's 3.3.0.* with hotfixes and 3.3.1.* in development? Is there a big difference?
E: I need to think a bit about this....

Quote from: BigMc on Fri 19/09/2014 20:01:53
I think most users get AGS from the homepage where only stable releases are found or not?

I mean, we will have to explain why the previous version was 3.4 and new one suddenly 3.6. Your examples are both low-level developer tools, and AGS is a common user product.

Anyway, I like that scheme. It's a matter of taste. AGS is also for developers...

Should I rename the 3.3.1 threads to 3.4.0? I've been thinking about it, but I don't want to cause confusion with the _other_ 3.4.0.

We need to get to conclusion on version numbering first. Let me think till tomorrow, I want to consider what BigMC said.

As for "another 3.4.0", I doubt it is really used for any project right now. It was an experimental build with temporary name.

Quote from: Crimson Wizard on Fri 19/09/2014 20:17:11I mean, we will have to explain why the previous version was 3.4 and new one suddenly 3.6. Your examples are both low-level developer tools, and AGS is a common user product.

I agree with this. I think that in general the way the versioning is controlled now is appropriate. The way it's worked thus far, the first version number has actually corresponded exactly to major editor revisions (e.g., complete IDE rewrite). The secondary version number is generally increased when there are major changes to the editor or engine (script API changes, major bugfixes, etc.). The tertiary version number is then reserved for more minor changes, minor bugfixes, minor feature fixes, and the like. This all applies directly to the public release version numbers, and I think it works very well. The fourth version number being used to differentiate between development revisions (using even numbers for stable releases) also serves its purpose.

That being said, it may not be immediately obvious how the versioning works. Is this actually documented explicitly anywhere?

Quote from: monkey_05_06 on Sat 20/09/2014 04:15:54
The way it's worked thus far, the first version number has actually corresponded exactly to major editor revisions (e.g., complete IDE rewrite). The secondary version number is generally increased when there are major changes to the editor or engine (script API changes, major bugfixes, etc.). The tertiary version number is then reserved for more minor changes, minor bugfixes, minor feature fixes, and the like. This all applies directly to the public release version numbers, and I think it works very well.

That would all stay the same with the scheme I proposed, except that builds coming from a development branch would have the secondary version odd (and maybe a beta, rc, wip or whatever suffix to clarify) and builds from a stable branch have an even secondary version. Both increase once the development branch turns into a stable branch, i.e. a new major stable version is released.

Quote from: monkey_05_06 on Sat 20/09/2014 04:15:54The fourth version number being used to differentiate between development revisions (using even numbers for stable releases) also serves its purpose.

It appears to me that it's not used that properly; in fact I started to use it so after incorrectly understanding BigMC's suggestion when he made it first time (about a year ago).

Quote from: monkey_05_06 on Sat 20/09/2014 04:15:54
That being said, it may not be immediately obvious how the versioning works. Is this actually documented explicitly anywhere?

This might have been mentioned in few topics, I found an indirect reference here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0
And also this was the very first thread we discussed version numbers:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47581.0
//-----------------------------------------------------------------------------



Now, I took some time to think this over, and I should say that I saw logic in what BigMCs suggestion. Of course, that may be uncommon for AGS users.
Following is my IMHO.

What do we need version for? To let people know their order and meaning (major change, minor change).
Every public release, whether alpha, beta or final, should have distinct version visible to users (i.e. no hidden numbers, internal tags).

If we are working on version 1.2 and make beta releases, we must change version somehow, for example add the third number: 1.2.1 is first beta, 1.2.2 is second beta, and so forth.
When we release a final/stable version, we need to somehow emphasize that this is the next stage of a program, not WIP/beta anymore. If we just increase auxiliary number one more time (e.g. make it 1.2.3), we won't achieve this, because it will blend with WIP versions.
For the very first alpha/betas developers often use numbers starting with 0 (e.g. 0.5.1); however, this can hardly work for the next versions.

AGS has a tradition of X.Y.Z stable releases (generation, major, minor), but also has the fourth number, which was used only for internal purposes. In the times of SVN repository this number was probably equal to SVN revision (commit) number. Today it lost its meaning, because:
- in Git there's no commit number, there's commit hash (which lets to identify particular commit, but, unfortunately, does not tell anything about its order);
- public releases require a change of one of the "public" numbers;
- developers and repo users does not need this "internal" number either, because they know which commit they used to build the program.
- when there are at least two branches, both of which may have public updates, it is impossible to have a single sequence of "revision" numbers in a proper order.

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

The conclusion:

1. Version should visibly change at every public release. By "visibly change" I mean that the end-user should be aware of numbers, and their meaning and order should be clear to him/her.
2. We would benefit from distinct change in numbers when WIP version changes to stable version.
3. The fourth version number lost its meaning and should be either removed, or utilized differently.
4. The upcoming 3.4.0 version may be the starting point of introducing new version numbering (whichever is chosen).

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

What is the solution referenced by BigMC? It is to make the version number increase every time we move from stable to WIP and back to stable. For example:

3.4 is stable version and 3.4.* are stable version updates
3.5 is a WIP version and 3.5.* are WIP updates; when 3.5 is completed, it is changed to stable 3.6.0, and next WIP is 3.7.0 (started simultaneosly).

Optionally, if we are using three numbers for stable release and fourth number for updates:

3.4 is a major stable version and 3.4.0.* are stable version updates
3.4.1 is a minor WIP version and 3.4.1.* are its updates. When 3.4.1 is completed, it is changed to stable 3.4.2, and next WIP could be 3.4.3.
3.5 is a major WIP version (same as above), which will end as 3.6, the next major stable version.



What are alternative solutions? I know only one: stable version updates follow up WIP versions, for example:

3.4.0 is the alpa, 3.4.1, 3.4.2 are betas, 3.4.3 is the first stable release. This won't cause "jumps" between stable releases, but change between WIP and stable will be less distinct. Whether it is a problem or not is a subjective question, IMO.

EDIT: if we use fourth number, then, for example, 3.4.0.0 -> 3.4.0.4 are betas and 3.4.0.5 is first stable. This keeps the first three numbers the same as end-user would expect, and utilizes fourth number as "developer update". But it must be included to package name.
Actually, thinking more about this, I like four-numbers sequence better.


What do you think?

I wonder what 3.5.2 is, a stable WIP version???

I know projects do even/odd numbering, but I have never seen it applied at sub-number level yet. I believe most users will not understand that 3.4.3 is a WIP, and they should instead download 3.4.2. The usual idea is "higher number  == better".


Why not make unstable versions explicit?  3.4.2-beta1 (or -wip or -rc or -dev), 3.4.2-beta2 ... to release 3.4.2, with updates or fixes 3.4.2.1 , 3.4.2.2 etc.
After 3.4.2, develop 3.4.3-beta1.  You could use different suffixes for different goals, 'beta' or 'wip' for just an intermediate version, 'rc' for a test build of the next stable (ie no big new things will be added before the release). Don't know if you need that, it may add very little, yet adds to the complexity of releases.

After reading your older post about branches http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0, I think 'develop' itself should not have a version number at all, you could use 0.0.0.<git-hash> if you need to build it.
A version number (like 3.4.2 or 3.4.3-beta1) should be decided in the release branch, where you (in my opinion) can pick any number bigger than what you have already released. For example, if a huge new feature is added after 3.4.3-beta1, you could jump to 3.5-beta1 or even 4.0-beta1 (assuming you always have 2 numbers at least). Another option is to make such number decisions just before the next release, and not before (ie keep 3.4.3-betaX no matter what is added). That may be easier for the release process and less confusing for people to follow.

I am still puzzled by the 'master' branch. Suppose 2.6.4 has been released. It's on the master branch. Next I bring out 3.7, and then find a bug in 2.6.4. Where would 2.6.5 go? It seems to me the 'master' branch is making things complicated if you have several release branches in parallel. Is there anything wrong with just making a branch off develop for every major new version (say 3.4), and update that branch to 3.4.1 etc ?
(Just puzzling why the 'master' exists, from a release theoretic point of view, if you don't need the extra complexity, by all means keep what works for you.)

Quote from: Alberth on Sat 20/09/2014 16:53:35
After reading your older post about branches http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0, I think 'develop' itself should not have a version number at all, you could use 0.0.0.<git-hash> if you need to build it.

This is the question of public version, not naming the branch. The branch can be named in any way which is convinient for developers; and if developers make some build for themselves, they can again call it as they please. However here we discuss the version as seen by users; and release version should have clear meaning for them. End-users don't know what "git-hash" is, how will they know this version is the next beta or whatnot?

Quote from: Alberth on Sat 20/09/2014 16:53:35
I am still puzzled by the 'master' branch. Suppose 2.6.4 has been released. It's on the master branch. Next I bring out 3.7, and then find a bug in 2.6.4. Where would 2.6.5 go? It seems to me the 'master' branch is making things complicated if you have several release branches in parallel. Is there anything wrong with just making a branch off develop for every major new version (say 3.4), and update that branch to 3.4.1 etc ?
(Just puzzling why the 'master' exists, from a release theoretic point of view, if you don't need the extra complexity, by all means keep what works for you.)

If a bug is found in older version, and the users using it can't rightly update to bigger version (for example, it has some compatibility problems), then there's another branch created, e.g. "2.6.5", branching from last 2.6.4 commit in "master"; the bugs are fixed there, and the 2.6.5 update is released. The changes from 2.6.5 can then be merged to latest master.
Hypothetically, if there are other intermediate versions that have to be updated, similarily we may branch out of correspoinding point in history and merge the fixing branch there.

Sort of this:


       2.6.5     3.0.1                 3.7.1
        *---------*---------------------*--------
       /         /                     /         
------*---------*---------------------*------------* -> go on with development
     2.6.4      3.0                   3.7


This is possible, although AFAIK was never used in AGS before, usually all bugs are fixed in the next version (if they still apply).
Since this is now open source project things may change.

No particular opinion on this (different sub-version numbers for dev and release versions), as long as the numbers keep going up. I guess personally I'd mildly prefer not to have the second-level version update increment by two between every stable release, but as long as you pick a system you're happy with it doesn't seem like it really matters.

As for Alberth's objection about people "not understanding" that a later version isn't always better, it's common for open source projects to have a link to a stable release (which is what the default download button gives you) as well as to a wip version (whether it's called a beta, a development branch or whatever) with a higher version number. As long as they're clearly labeled and the default is set correctly (and the stable release doesn't lag the beta by too much), it shouldn't be a problem.

Quote from: Crimson Wizard on Sat 20/09/2014 17:22:41

Quote from: Alberth on Sat 20/09/2014 16:53:35
After reading your older post about branches http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0, I think 'develop' itself should not have a version number at all, you could use 0.0.0.<git-hash> if you need to build it.

This is the question of public version, not naming the branch. The branch can be named in any way which is convinient for developers; and if developers make some build for themselves, they can again call it as they please. However here we discuss the version as seen by users; and release version should have clear meaning for them. End-users don't know what "git-hash" is, how will they know this version is the next beta or whatnot?

I am aware of that.
I see a build of 'develop' as something for developers. It's generally useful to be able to build such a thing 'out of the box', that's why I attached a weird but unique number to it.

For public versions, I proposed to name it "next-version"-betaN, where "next-version" is the 2-number prefix of the last release, with the second number incremented by 1 (3.4 -> 3.5, 4.9 -> 4.10), and "N" incremented by one with each release.
Number would be assigned in a release branch.

Quote from: Crimson Wizard on Sat 20/09/2014 17:22:41
Sort of this:

Code (text) Select Expand


       2.6.5     3.0.1                 3.7.1
        *---------*---------------------*--------
       /         /                     /         
------*---------*---------------------*------------* -> go on with development
     2.6.4      3.0                   3.7


This is possible, although AFAIK was never used in AGS before, usually all bugs are fixed in the next version (if they still apply).
Since this is now open source project things may change.

Ah yes, you'd forward-port the fix to the newest releases too. That would make sense.

Sorry, post deleted. I see your point.

Well, this needs to be resolved somehow...

Although I honestly see a certain benefit of BigMC's suggestion I am being held back by the consideration that this will be very uncommon for the most users of AGS.
My own personal opinion is to continue using same versioning scheme for now, but include fourth number to the public release (package) name as "development number" and reset it to 0 every time we change any of the first three. This way people would be able to clearly see the progress when we release intermediate WIP versions.
Of course, the "stage" releases, even fixing or updating existing versions, should have the third number changed (at least).
If we need to underline that the public release is WIP, we may add something to its package name (alpha, beta, rc), and stop doing that as soon as it reaches first stable version.

If later we will see that there are clearly problems with distinguishing between WIP and stable releases, we may consider using BigMC's suggestion, starting with 3.5 (which, conveniently, is a proper number for WIP version).

Regarding this

Quote from: Alberth on Sat 20/09/2014 18:19:35
Number would be assigned in a release branch.

Thing is that we start making "intermediate" WIP releases for public early in development, and we must number them somehow. IMHO choosing next "big" number (i.e. 3.5 after 3.4.* was released) is a logical thing.
(The highest number means "generation", and it rather supposes that we have rewritten a huge part of program from scratch. Such changes can't be applied on WIP branch with additions to previous version, because that makes little sense).
As for minor numbers, idea originally was to start developing them only when there's a need to quickly update one of the previously (recently or not) released version. Currently we have a "3.3.1" WIP, which is incorrect, and is actually my mistake breaking the rule I've proposed myself, and we plan to change it to 3.4.0.
Previously we've had a situation when we had 3.2.2 WIP version that was merged with more features, and we decided to not release 3.2.2, but change it to 3.3.0, and that is how it was finally released.

Does it matter if it's uncommon for users?

All users care about is if the numbers go upwards. We don't make formal releases for dev releases anyway so most users will just use the stable version.

Quote from: Calin Leafshade on Sun 21/09/2014 15:58:38
Does it matter if it's uncommon for users?

All users care about is if the numbers go upwards. We don't make formal releases for dev releases anyway so most users will just use the stable version.

Do you honestly believe that given a choice between 3.5.5 and 3.4.2, all users will pick 3.4.2?

Even if you have a few users making the wrong choice, you will end up with mess explaining to them they picked the wrong one, with a difficult explanation about odd and even numbers, etc.

Projects like a kernel are different; they have looooong development times, and many distributions (red-hat enterprise, centos, etc) stick to the last stable for 7+ years.
Also, unlike a user application like AGS, people don't generally install kernels themselves, they pick whatever their distribution provides. That means the public for a kernel is much more professional than Joe average Window user.

Quote from: Alberth on Sun 21/09/2014 16:09:45
Also, unlike a user application like AGS, people don't generally install kernels themselves, they pick whatever their distribution provides.

Well, to be honest, for AGS most people do install the version referenced from main website page. And when we post WIP versions on forum we warn that these are WIP.
I can't be sure whether they do or do not care what numbers are there...

E: Damn, I am too meek :). Now Calin made me doubt once again.

These hotfixes need to be advertised better. I didn't know there was a third hotfix until I just happened to need to redownload AGS.
I also remember talking to Adeel around the time of the second hotfix, he didn't know there was one.
We both spend a stupid amount of time on these forums.

Please don't take this as ungrateful, I appreciate the amount of work that goes into supporting this software.

Quote from: Retro Wolf on Sun 21/09/2014 16:25:21
These hotfixes need to be advertised better. I didn't know there was a third hotfix until I just happened to need to redownload AGS.
I also remember talking to Adeel around the time of the second hotfix, he didn't know there was one.
We both spend a stupid amount of time on these forums.

Yes, this was my mistake, we will have a version change every time these are made from now on.

I still maintain that the four-point version system works well. I agree with the suggestion to start resetting it though.

And that's about all that I can usefully say on that for now. :P

Ok, let's make current WIP version 3.4.0.0, keep incrementing 4th number as we make intermediate updates. When we will approach release branch, we may consider to change (increase) version, if it would appear that there's a problem with keeping it 3.4.

This sounds like an appropriate direction to me. At the very minimum the public stable releases will have their tertiary version number increased (including for hotfixes and updates), and the fourth version number will be reserved for WIP releases. The "generation" and "major" version numbers will continue to be used as they historically have been. Yeah? 8-)

Quote from: Crimson Wizard on Sun 21/09/2014 16:59:49
Ok, let's make current WIP version 3.4.0.0, keep incrementing 4th number as we make intermediate updates. When we will approach release branch, we may consider to change (increase) version, if it would appear that there's a problem with keeping it 3.4.

Surely the fourth number could just represent hotfixes? So 3.3.0.3 is 3.3 hotfix 3?

Quote from: Sslaxx on Tue 23/09/2014 12:46:24
Surely the fourth number could just represent hotfixes? So 3.3.0.3 is 3.3 hotfix 3?

Right.

Just few thoughts on this new 3.4.0 version. I guess we have at least two core features that would determine it already:
1. Custom resolutions.
2. Dynamic user structs in script.
+ quite a few nice additions to both script language and API.

I believe that if we'd focus in completing these, we'll get a good "basis" for the next "official" release.

Other features of interest:
* Building game for multiple platforms;
* Try to fix/reimplement the threaded audio;
* ?


Regarding future development, and specifically full limit removal: there are many things that were either planned, or implemented in the experimental "develop" branch, that would require breaking backwards-compatibility. I mean savedgames format and (engine's) plugin API. If we won't change these, in time they will become a permanent headache.
The savegame format change would only hurt port-users, and only if they would migrate from older engine versions in the midst of playing particular game (which sould not normally happen).
Plugin API is a more serious task, also this will disable existing plugins for the new version. But regardless, I believe this must be done.
So, I was thinking, that maybe this 3.4.0 should be the last version that strictly maintains the backwards-compatibility.

Quote from: Crimson Wizard on Wed 24/09/2014 18:28:34* Building game for multiple platforms;

On that note, I have partially refactored building the data file out of the native code. I'll need to work on it some more (hopefully this weekend) and then I can incorporate it into the Linux build process which I've already streamlined into the editor code. It's currently not building correctly, though most of the data seems to be getting copied. Just need to review it and figure out what I've mucked up.

I think I'm late to the party with the version number thing but I'll give my opinion anyway. I don't think we need a fourth number. You could release 3.3.0 hotfix 4 as "3.3.2". We could mark 3.3.1 as abandoned. That way there's no confusion between it and the old develop-3.3.1 branch. It will just be like we skipped 3.3.1. When 3.4.0 is released, we can use the third digit for hotfixes. e.g. 3.4.1, 3.4.2, 3.4.3.

For 3.4.0, I have the following definites:
* Runtime Type Information table -- if I ever figure it out
* switch...case statement -- just need time to implement this, I know how the assembly should look

Aaaand lots of others in various states:

Spoiler

Maybes:
* Allow variable declarations in a for loop's initialiser (e.g. for(int i = 0; ...)
* Locking of room objects (like locking GUI controls) -- I started on this and have a patch somewhere
* Type coercion of ints/floats to make maths functions more beginner friendly

Won'ts:
* Use a web browser control for the AGS start page -- too many issues with the docking suite, no point really
* Custom speech rendering (like custom dialog rendering) -- would love it, but it's soooo complicated

[close]

I would also like to present another tiny addition to AGS and see what others think. Currently in winsetup.exe, when choosing a language, the default is called Game Default. To me, Game Default doesn't tell the user anything about the language they're choosing. I would like to be able to optionally name the default language in the general settings of a project so that it could be listed in the dropdown like:
English (Default)
Deutsch
Magyar

What do you guys think? Is this silly? I would really like it because I plan to offer American English with British English as a translation (confusing at the best of times!). I thought I might be able to squeeze it in as we're overhauling winsetup.exe in 3.4.0 anyway.

Regarding limits, CW, can we merge stuff from the "no limits" branch of AGS where it won't break the save file and game file formats?

Oh, and monkey_05_06 I'm very excited about being able to target Linux from the editor! Would love it for 3.4.0

Quote from: Gurok on Thu 25/09/2014 05:55:18
I think I'm late to the party with the version number thing but I'll give my opinion anyway. I don't think we need a fourth number. <...> When 3.4.0 is released, we can use the third digit for hotfixes. e.g. 3.4.1, 3.4.2, 3.4.3.

Alright, we are getting confused again, and I realized I could cause it with my recent post, where I ... well, did something wrong.
Yes, right, as I said earlier, every public release of the stable version should have a new 3rd number. The 4th number is used for WIP intermediate releases, when the development takes longer times and we need to distinguish the stages when making demo/test releases. Practice showed that several people could use even those to compile their games.
Again: the 3rd number update means we reached next stable stage, while 4th number means we are still in the midst of development process, and the program may have incomplete things and features added for testing.

Quote from: Gurok on Thu 25/09/2014 05:55:18
You could release 3.3.0 hotfix 4 as "3.3.2". We could mark 3.3.1 as abandoned. That way there's no confusion between it and the old develop-3.3.1 branch. It will just be like we skipped 3.3.1.

If we care of confusion, this could cause more confusion by making people wonder why 3.3.2 does not have 3.3.1 features too. :)
But... alright. This has sense too. We would just need to add a comment about why the minor number was skipped.

Quote from: Gurok on Thu 25/09/2014 05:55:18
* Custom speech rendering (like custom dialog rendering) -- would love it, but it's soooo complicated[/spoiler]

Some design ideas here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48518.0
But that would require refactoring the speech functions very carefully.

Quote from: Gurok on Thu 25/09/2014 05:55:18
I would like to be able to optionally name the default language in the general settings of a project so that it could be listed in the dropdown like:
English (Default)

I agree, and I think this won't be complicated if you put the default language name in config file. For winsetup is not taught to read game data.
You could also add this to the game data too, so that it could be used with script API (i.e. ChangeTranslation would detect that you are demanding default language if you will pass its custom name).

Quote from: Gurok on Thu 25/09/2014 05:55:18
Regarding limits, CW, can we merge stuff from the "no limits" branch of AGS where it won't break the save file and game file formats?

That is what I was planning to do right after I finish with custom resolutions.
http://www.adventuregamestudio.co.uk/forums/index.php?topic=49969.msg636492480#msg636492480
I kept myself from doing this earlier fearing that this will cause merging conflicts with CR branch.

I made a new branch: https://github.com/ivan-mogilko/ags-refactoring/tree/alpha-proposal-3.4.0
Maybe we could make a next alpha version from it. I'd rather have it tested tad more before merging my own pull request (https://github.com/adventuregamestudio/ags/pull/190). Of course, constructive critisism on code is welcome too.

I have a question regarding displaying a custom property in the editor.
Here's the commit I made a while ago with Custom Resolution dialog: https://github.com/ivan-mogilko/ags-refactoring/commit/f2e258124a9205725c565fda856313c0c3f811ac

Initially I wanted to use just Size for custom resolution property, but it was displayed as "Width=X; Height=Y" on General Properties pane, and I wanted it to be displayed as "X x Y" for aesthetic reasons.
Back then I was in a hurry and did not find better way than to create a new class, wrapping Size, and overriding "ToString" method.
Is there simplier way?


EDIT: I should probably ask differently. If I understand correctly, ToString is meant to display information on object state, rather than user-aimed text. How can make the property list display property value using some custom function rather than calling object's ToString?
Some attribute maybe? I am not very knowledgeable in this area.

The class you need is UITypeEditor

then you need to decorate the property with the Editor attribute

I believe the sprite picker in the property grid is implemented this way.


class Foo
{
    [Editor(typeof(FancyStringEditor), typeof(UITypeEditor))]
    public string Bar { get; set; }
}
class FancyStringEditor : UITypeEditor
{
    public override UITypeEditorEditStyle GetEditStyle(ITypeDescriptorContext context)
    {
        return UITypeEditorEditStyle.Modal;
    }
    public override object EditValue(ITypeDescriptorContext context, IServiceProvider provider, object value)
    {
        var svc = (IWindowsFormsEditorService)provider.GetService(typeof(IWindowsFormsEditorService));
        if (svc != null)
        {
            using (var frm = new Form { Text = "Your editor here"})
            using (var txt = new TextBox {  Text = (string)value, Dock = DockStyle.Fill, Multiline = true })
            using (var ok = new Button { Text = "OK", Dock = DockStyle.Bottom })
            {
                frm.Controls.Add(txt);
                frm.Controls.Add(ok);
                frm.AcceptButton = ok;
                ok.DialogResult = DialogResult.OK;
                if (svc.ShowDialog(frm) == DialogResult.OK)
                {
                    value = txt.Text;
                }
            }
        }
        return value;
    }
}


Quote from: Calin Leafshade on Tue 30/09/2014 10:13:04
The class you need is UITypeEditor

then you need to decorate the property with the Editor attribute

I believe the sprite picker in the property grid is implemented this way.

Spoiler

Code (c#) Select Expand


class Foo
{
    [Editor(typeof(FancyStringEditor), typeof(UITypeEditor))]
    public string Bar { get; set; }
}
class FancyStringEditor : UITypeEditor
{
    public override UITypeEditorEditStyle GetEditStyle(ITypeDescriptorContext context)
    {
        return UITypeEditorEditStyle.Modal;
    }
    public override object EditValue(ITypeDescriptorContext context, IServiceProvider provider, object value)
    {
        var svc = (IWindowsFormsEditorService)provider.GetService(typeof(IWindowsFormsEditorService));
        if (svc != null)
        {
            using (var frm = new Form { Text = "Your editor here"})
            using (var txt = new TextBox {  Text = (string)value, Dock = DockStyle.Fill, Multiline = true })
            using (var ok = new Button { Text = "OK", Dock = DockStyle.Bottom })
            {
                frm.Controls.Add(txt);
                frm.Controls.Add(ok);
                frm.AcceptButton = ok;
                ok.DialogResult = DialogResult.OK;
                if (svc.ShowDialog(frm) == DialogResult.OK)
                {
                    value = txt.Text;
                }
            }
        }
        return value;
    }
}


[close]

I could not do this with UITypeEditor alone, because I need the property type to be Size, not string, and also I wanted to forbid user to type right in the property field.

I was able to do this with TypeConverter though.

Can someone check if it looks good?
https://github.com/ivan-mogilko/ags-refactoring/commit/742b9a47ac2a2516725be3823218179d1357cb88

I haven't had proper practice with C# for about two years now :(. Should reread some books perhaps.

For compatibility with demo CR builds I had to make a custom serialization selected by property name (didn't want to force all properties of Size type to use it). I think it needs some attribute to make a generic solution. I'll try this next.

An update, FYI.

I've already merged custom-res into 3.4.0 branch, there's just one minor issue that does not work well in the engine. I hope there will be next alpha release soon (maybe this weekend). It also contains unlimited controls on GUI for Knox :).

After this I am planning to devote time to further refactor/improve engine code, because there were already few wanted changes that could not be added easily because of complexity of the code.
Also look into fixing some old problems.

Regarding changing savedgame format. Earlier I mentioned that I would rather wait till another major version, but upon further consideration I realized that it won't hurt that much to make one in 3.4.0 (or simply extending save data made by this version if needed). Even if the 3.4.0 alpha is used to develop games, users won't be keeping savegames for a long time anyway, because their games are constantly modified.
Correct me if I missed something.

Gurok, I have a question to you. In 3.3.1 you've introduced LastBuildConfiguration property, which helps to detect when full rebuild is required.
It is saved in the main project file. Now when I think about this, I find this somehow wrong, because it is not directly a part of project data, but description of its dynamic state (if you got my meaning).
There's already "Game.agf.user" file for storing user-related properties for the project (not sure it does anything, I think it is meant to save some data about integrated source control).
Could we create some kind of project state file in a similar fashion, and save project's dynamic state there?
I guess, if the file is not found, editor should always act as if LastBuildConfiguration is different from current one.

I'll take a look at this. Shouldn't be hard.
I believe that's the way the editor currently acts with regard to LastBuildConfiguration. I'd have to check.
I think it's just a case of moving it from one config file to another.

Quote from: Gurok on Thu 23/10/2014 09:58:19
I'll take a look at this. Shouldn't be hard.
I believe that's the way the editor currently acts with regard to LastBuildConfiguration. I'd have to check.
I think it's just a case of moving it from one config file to another.

The AGS serialization works in such a way that it saves every public property with "setter" into xml, without any other discretion.
If you would like to save property into different file instead, there should be some mechanism implemented, that would define the target config file for a property.
Alternatively, this property may be moved to a different class, that saves all of its contents to different config.

OTOH, when XML describes a property which no longer exists in a class, AGS raises "wrong version" error. Therefore, if any obsolete property is removed, such situation must be resolved to let open old projects.

Some time ago I made an attribute in case we would need to completely remove a deprecated property from some class:
https://github.com/adventuregamestudio/ags/commit/74d6f165e03b728006efc0b786518b044088f9bf

I do not know how you will deal with LastBuildConfiguration; but if you will want to remove it from the Settings class completely, you could use this attribute to suppress such errors, like this:


[DeserializeIgnore("LastBuildConfiguration")]
public class Settings : ICustomTypeDescriptor



E: I don't really have a big interest in designing editor code (engine is pretty much enough for me), so if anyone have better concept, please tell so.

Hey CW, just wanted to say thanks for eliminating that UpdateCPPVersion utility. Building is so much easier now without it!

MOAR AGS MADDNESS INCOMING!!!

http://www.mediafire.com/download/rd3dcx9kbq7k71d/test_audio_speed.zip

Could not resist :).
Thanks to Gord10 for this wonderful idea!

Hey CW, Game.agf.user is supposed to be used for "Interface to persist user-specific data to/from disk. This data will not be checked into source control". Does LastBuildConfiguration count as user-specific data or do you want a new file (e.g. Game.agf.state)? I am thinking that one non-source controlled file per project is really enough.

Quote from: Gurok on Tue 28/10/2014 22:01:41
Hey CW, Game.agf.user is supposed to be used for "Interface to persist user-specific data to/from disk. This data will not be checked into source control". Does LastBuildConfiguration count as user-specific data or do you want a new file (e.g. Game.agf.state)? I am thinking that one non-source controlled file per project is really enough.

I honestly don't know, just confused by the "user" suffix. IMO the project state and user settings are different thing, but I am not sure what this file was for. IIRC it was monkey_05_06's idea to create *.user file, maybe consult with him about this.

The .user file was not, in fact, my idea. 8-) It was implemented by CJ around AGS 3.0.2:

Quote from: Pumaman (http://www.adventuregamestudio.co.uk/forums/index.php?topic=34401.msg449765#msg449765)

Quote from: monkey_05_06Edit: BTW Chris, what is this Game.agf.user file that seems to have cropped up?

It's for storing any settings that are specific to you (the user of the AGS Editor) and not game settings.
At the moment it's only used to store source control information, but in future it might also contain which windows you had open when you closed the editor, etc.

Based on this, I would say it makes sense to keep this type of info in that file (since it's not really project data).

Quote from: monkey_05_06 on Tue 28/10/2014 23:33:26
The .user file was not, in fact, my idea. 8-) It was implemented by CJ around AGS 3.0.2:

Quote from: Pumaman (http://www.adventuregamestudio.co.uk/forums/index.php?topic=34401.msg449765#msg449765)

Quote from: monkey_05_06Edit: BTW Chris, what is this Game.agf.user file that seems to have cropped up?

It's for storing any settings that are specific to you (the user of the AGS Editor) and not game settings.
At the moment it's only used to store source control information, but in future it might also contain which windows you had open when you closed the editor, etc.

Based on this, I would say it makes sense to keep this type of info in that file (since it's not really project data).

Oh fantastic. Thanks, Monkey.

Mhh so now there are tags called v.3.4.0.0 and v.3.4.0.1 in the development branch. That's super confusing. What will be the version of the next stable release?

If there are no version numbers reserved for development releases as in my suggestion then a version like 3.4.0.0 sounds like a stable release and all development versions before that can only be called 3.4.0.0-alpha1, 3.4.0.0-alpha2, 3.4.0.0-beta1 etc. Remember that version numbers should increase so you can't go back from 3.4.0.1-alpha1 to 3.4.0.0.

Also the tags don't have an "alpha" so they look like stable releases.

Quote from: BigMc on Fri 31/10/2014 21:44:45
Mhh so now there are tags called v.3.4.0.0 and v.3.4.0.1 in the development branch. That's super confusing. What will be the version of the next stable release?

It will be 3.4.0.something.

Quote from: BigMc on Fri 31/10/2014 21:44:45
Also the tags don't have an "alpha" so they look like stable releases.

Okay, I'll add alpha to them.

What's Release_MD in the build configuration list for the editor?

Quote from: Gurok on Sat 01/11/2014 14:45:49
What's Release_MD in the build configuration list for the editor?

It uses /MD compilation flag for Common and Compiler static libraries, which tells them to link runtime C++ library dynamically, as opposed to /MT which links them statically.
I had to change to /MD after we started to use STL, otherwise Common.lib caused linker errors when linking to AGS.Native.
/MT is still used for the engine.

Now the tags are:

3.4.0.0-alpha1
3.4.0.1-alpha2

You can get rid of either of the last two numbers. Either

3.4.0.0-alpha
3.4.0.1-alpha

or

3.4.0-alpha1
3.4.0-alpha2

would be fine. Or am I missing something? I like the last variant better.

Quote from: BigMc on Sun 02/11/2014 07:51:51
Now the tags are:

3.4.0.0-alpha1
3.4.0.1-alpha2

You can get rid of either of the last two numbers. Either

3.4.0.0-alpha
3.4.0.1-alpha

or

3.4.0-alpha1
3.4.0-alpha2

would be fine. Or am I missing something? I like the last variant better.

The last number defines the consequent index of release. So it may be:
3.4.0.1-alpha
3.4.0.2-alpha
...
3.4.0.10-alpha
3.4.0.11-beta
...
3.4.0.25-rc
3.4.0.26-final
3.4.0.27-hotfix

Having all 4 numbers would be easier for me to understand its position in the history. So I'd rather keep it.

Ok but I thought we wanted to get rid of the final and hotfix suffices. So no suffix would correspond to a stable release.

Quote from: BigMc on Sun 02/11/2014 14:11:55
Ok but I thought we wanted to get rid of the final and hotfix suffices. So no suffix would correspond to a stable release.

IIRC the problem I was addressing was that I was naming releases with suffixes only (e.g. 3.3.0-hotfix1, 3.3.0-hotfix2), instead of increasing visible version number.
As I see this, the numbers define unique index of the version, while suffix is an auxiliary description.

Ok I'll keep quiet as long as the versions are strictly increasing. :) I find this scheme much more weird than what I proposed though. :-D

Just saw that my pull request for building Linux (https://github.com/adventuregamestudio/ags/pull/209) got approved. :-D

Is there any specific timeframe as to when the next alpha/beta version is expected? I know there's been some pretty significant changes since 3.4.0.1, so it would be good to have an "official" build for people to test out these new features. ;-D

Quote from: monkey_05_06 on Mon 10/11/2014 23:33:27
Is there any specific timeframe as to when the next alpha/beta version is expected? I know there's been some pretty significant changes since 3.4.0.1, so it would be good to have an "official" build for people to test out these new features. ;-D

No, no specific timeframe, I am rather using "weight" of accumulated changes as a reference. And yes, I was going to make a new build, maybe in several hours.

Say, how do you make the Linux folder for the editor? What it consists of? Are there any specifications?
How do I build the linux binaries for 32-bit and 64-bit? Maybe some instruction exists?

Can I take it from this archive (https://bitbucket.org/monkey0506/ags/downloads/3.4.0.2+linux.rar), or linux binaries must be rebuilt anew?

It's built using the script debian/make_ags+libraries.sh on Debian or Ubuntu (see comments in the file for instructions) and of course it should be built with the latest code if you want to make a release.

Yes, it's just the folders/files that the make_ags+libraries.sh script produces (copy the data folder, sans any game files). I can do a fresh build this afternoon if needed.

Quote from: monkey_05_06 on Tue 11/11/2014 13:28:07
Yes, it's just the folders/files that the make_ags+libraries.sh script produces (copy the data folder, sans any game files). I can do a fresh build this afternoon if needed.

Yes, please.
I am getting some errors for "cowbuilder" thing, I'll need more time to understand how all this works.

Which errors? Did you follow the instructions?

Quote from: BigMc on Tue 11/11/2014 19:09:25
Which errors? Did you follow the instructions?

I followed them up to the

Quote
# Create the (chroot) environments that will be used for building ags:

# cowbuilder-dist wheezy i386 create
# cowbuilder-dist wheezy amd64 create

I do not really understand what this means. Are they the exact commands I should type, or I must also add some custom parameters here?
When I ran the first one, I get this:

Quote
ikm@ubuntu:~/git/ags$ cowbuilder-dist wheezy i386 create
-> Invoking pbuilder
  forking: pbuilder create --logfile /home/ikm/pbuilder/wheezy-i386_result/last_operation.log --othermirror deb http://security.debian.org wheezy/updates main contrib non-free|deb http://ftp.debian.org/debian wheezy-updates main contrib non-free|deb http://ftp.debian.org/debian wheezy-proposed-updates main contrib non-free --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg --components main contrib non-free --debootstrapopts --arch=i386 --buildplace /home/ikm/pbuilder/wheezy-i386-base.cow --mirror http://ftp.debian.org/debian --architecture i386 --distribution wheezy --no-targz --extrapackages cowdancer
W: /home/ikm/.pbuilderrc does not exist
I: Logging to /home/ikm/pbuilder/wheezy-i386_result/last_operation.log
I: Running in no-targz mode
I: Distribution is wheezy.
I: Building the build environment
I: running debootstrap
/usr/sbin/debootstrap
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
E: Release signed by unknown key (key id 6FB2A1C265FFB764)
E: debootstrap failed
W: Aborting with an error
pbuilder create failed
  forking: rm -rf /home/ikm/pbuilder/wheezy-i386-base.cow

I don't know why the key is missing but
http://marek.php5.sk/?p=150

Sorry this took me a bit longer than I thought it would, but here you go (https://bitbucket.org/monkey0506/ags/downloads/AGS-3.4.0.2-Linux.rar). Again, this is just the contents of the "data" folder produced by running the make_ags+libraries.sh script, and should be extracted to AGSEditor/Linux. This is based on the latest commit to develop-3.4.0 (https://github.com/adventuregamestudio/ags/commit/7aaf213280ec6ef568cf93e50d6b22c84d61ab81).

I suddenly realize I really want to stop doing this....
For the last four or five years all I do is fixing old and usually ugly code. I do that on my fulltime job, and I do that in spare time with AGS. I feel like forgetting how to write a new and good one. Word "tired" can not describe this, I think "fed up" suits this best.
I am also not really good at working with low level code, like utility algorithms; I would really prefer using someone's library, but I have to hack the utility functions, like graphic ones, all the time in AGS. I feel like I am not doing what I wanted to.
I remember back in 2009 maybe, I wanted to make some games, but I wasn't able, and I have no free time now; while everyone around do that. So I grow even more jealous over time.
I know this may look like childish emotions, but I can hardly help myself.
:embarrassed:

Hey, CW. I'm sorry to hear this. I try my best to help out, but not one of us has the time to spend on AGS that you've been putting in lately. Please take a little break, you sound so stressed. If we limit the scope of 3.4.0 we might have an easier time getting something released and some of the new features out to the public.

I have honestly been sticking to the sidelines mostly because I want to speed along the release of the next version. I don't think I've committed anything recently that hasn't been a fix for a regression or a bug I've introduced. I would love to help with the magic pink transparency bug (which I assume is the cause of this tension), but I have no idea where to start.

Some people might say that the hardest part of making a game with AGS is just making a start. But I know for you it's more complicated. You feel a duty to the community to maintain AGS. It's true that without you it's harder, but if you need to take a break, please don't beat yourself up over it. And if you took a break to work on a game, I don't think people would greatly mind.

Quote from: Gurok on Tue 13/01/2015 12:27:30I would love to help with the magic pink transparency bug (which I assume is the cause of this tension), but I have no idea where to start.

No, it is not a big problem on its own, I already know how to fix this.
But it just stresses me all the time that I am reimplementing something that is so common and might have been already implemented in much better way than I would be able to do.
Also the need to keep backwards compatibility always keep me wonder whether I must keep some buggy behavior to prevent breaking older games...
I really fail organizing the work process, and I keep postponing many breaking changes I was thinking of before, because I've lost belief in what I do here and reluctant to start new tasks.

On a lighter note: I think this photo best describes your feelings, CW:

Spoiler

[imgzoom]https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-xfp1/v/t1.0-9/10403345_331929090343219_4714677889064877546_n.png?oh=24a857f10316796f2a5bd431e4adeef2&oe=55294C65&__gda__=1428199660_94287edb276a0e1b0dc06837133c5cde[/imgzoom]

[close]

Quote from: Crimson Wizard on Tue 13/01/2015 10:14:54Word "tired" can not describe this, I think "fed up" suits this best.

Stop now is the only advice I can give you.
While it may feel wrong to give up, continuing isn't going to make it better.

Stop now, and do something else. Make a game (and just ignore all issues you encounter in AGS while doing that!), read a book, do nothing, write new shiny code in an unrelated project, whatever makes you happy again. Nobody in the community is going to be happy when you get fed up so much that you walk out (Including yourself is my guess after reading the responses, relieved yes perhaps, happy no.)

Once you cooled down enough to make sane decisions again, decide what you want to do, and if and how AGS fits in that. As you found out, the world has more problems and feature requests than you can manage. Heck, it has more than all developers in the world together can manage. There is no shame in choosing, it's essential to keep your sanity and happiness.

I survive by having 3 or 4 projects at most, and not playing a main role in all but one (anyone here for taking over FreeRCT? :D ) and jumping between them, but it's a personal thing. You will make a different choice, one that works for you.

Quoteand I have no free time now; while everyone around do that. So I grow even more jealous over time.

You're a slave to yourself only.

Nobody has free time, they make it by not doing some things. I have time to write this reply because I don't enter or solve issues for a game script, I don't code the new worldgen window in OpenTTD, I don't code queuing in FreeRCT, I don't make tea, and several other things I can/should do. Other people making eg a game can only do that by not doing other things. You don't have free time, you make it.

Do I feel bad about not doing those things? yes.
At the same time I also feel happy being able to write this message, hoping it's of use to you. At the end it feels like a good choice, even if it is not a very productive one in terms of code or tea. This what it is all about, in my opinion.

Make choices based on what you want, rather than what others want, or what you think others want. Until they pay you, they don't own your free time. (I know it's way easier to say than to do, but you are really in control here. Nobody will come to your house and beat you up because you skipped a day or a week working on ASG, it's safe to do that, really.)

QuoteI know this may look like childish emotions

I think it's brave that you express it here in public. No need to feel embarrassed.

QuoteI can hardly help myself

Here you are wrong, you can make a different decision. I bet you hesitated before opening the new post window, typing the message, and pressing Post. Yet you decided to do it.
In the same way, you can hesitate yet decide not to code AGS for one evening. If that is too long, decide to stop coding an hour earlier than usual. That's how you help yourself. Stop doing bad things by deciding you don't do them. It's as easy and difficult as that.

(And here I am, hesitating whether I want the world to know I wrote this quite personal message...
Yet hoping you can use at least some of it, I decide to go ahead, type this line, and press Post.)

I sympathize in more than one way.
I don't want to make personal suggestions, your post feels more like blowing off steam than asking for advice, but on a practical level,
at least the bit about the stress you feel when making changes, this is something probably shared by all who touched the code.
A possible (albeit partial) solution for that would be to have a set of unit tests, which would give developers more confidence that they're not breaking anything.
Of course this would be a massive undertaking and will require maintenance of its own, and will probably take a lot of time until it bears some fruit,
so maybe we're better off staying at this junction, stressed out and overwhelmed. :~(

@CW:
Take a break, have some rest and some fun. :)
(we still have a common game doc ;))

@to the whole community:
We should launch a poll about keeping or not the backward compatibility.
To be true, I don't see why we keep it (I mean, people can do without it easily).
And I guess it will be far easier and faster for the dev team if we renounce to it.
What is your opinion guys?

No, I should not have make this post. Now I feel even worse.
And please, don't make polls just because I was depressed other day. It is not how these decisions should be taken.

I hope I didn't add the last straw :-[

Quote from: Crimson Wizard
I remember back in 2009 maybe, I wanted to make some games, but I wasn't able, and I have no free time now; while everyone around do that. So I grow even more jealous over time.

Game creators and their games might bring a little happiness to a broader audience. But you engine coders make us game creators extremely happy :) It was like two birthdays stacked on each other, when 3.4.0.3 came out and included these dialog rendering improvements, a feature I've been hoping for since 2011.

Also if backwards compatibility is such a hassle, we should really discuss if it's still needed. I certainly do not need it.

Quote from: Crimson Wizard on Wed 14/01/2015 00:22:32
And please, don't make polls just because I was depressed other day. It is not how these decisions should be taken.

Don't worry, it's not about you, it's about the engine.
I think about it since ages and even made a topic almost one year ago on the french forum.
http://adventuregamestudio.fr-bb.com/t2288-ags-et-retrocompatibilite-necessite-ou-frein-sondage (http://adventuregamestudio.fr-bb.com/t2288-ags-et-retrocompatibilite-necessite-ou-frein-sondage)
As abstauber said : "we should really discuss" about it.

Ok, I suppose we should begin to wrap up the 3.4.0 development.

The most interesting new feature that still needs to be complete is User Objects with managed pointers inside, which in turn requires adding RTTI to script data. I think that it should be a priority (in features field).
Other than that, I do not think that we need to add any major features there.
Gurok, you were working on that before. Do you feel like being able to continue?

I will be finishing few things I was planning, then I'll fully switch to fixing bugs and improving existing features.

I will give it a try. My time is limited (as is everyone's). I have a couple of other things on the go right now:
- Support for variable declarations inside for loop initialisers (99% complete)
- Working out why AGD2's project has extra symbols when compiled under 3.4.0 (could be an unintended side effect of some other change)

To be honest, I've forgotten where I was up to, but I'll take a look at it during the week. I'm glad I saved the first pass in a Git branch.

I have been focusing on fixing bugs for some time now. I think most (90%+) of my recent commits have been fixes for bugs I've introduced :-[

Sorry for the double post. I took a look at this last night. It's just too much for me at the moment. I feel like I've already made some pretty big changes with scripting. These changes have resulted in little bugs here and there, and while I love AGS dearly, I don't want it chewing up even more of my time. I'm going to have to say I can't do it or we can leave it for later. Sorry.

Edit: To clarify, there will still be more pull requests incoming for regressions and/or bugs found by AGD2. I just don't have time to support even larger changes to the engine that I think would be required.

I was reminded today that this version does not have all features from Draconian Edition yet. And this after two years!!! I don't know how this is happening. I keep loosing track of things ((((((((((((((((((((((((
I need to make a list of draconian features that are still missing.


E: I was ill lately, so I stopped updating things, but I will be doing that again soon.

Just as a reminder, I also need to go through the DataFileWriter class and reimplement some error messages if there are too many of certain items that are still limited on the engine side. Unless of course those limits are similarly removed as the others have been.

I have a week off of school, so I will try to take that opportunity to look at this.

Just want to say the AGS Project Tracker team (is that the proper name?) is doing an awesome job!

Hi guys.

I have upgraded to 3.4.0 and thought that I may try to rebuild my game 'The Decorator' with it.
I understand that there are some changes to scripting commands but have I done this correctly.
Originally I had this. SetSkipSpeech(2); This made text un-skipable and only continue with timer.
AGS 3.4 doesn't like this and the only thing I can assume it could be now is. :-\ Speech.SkipStyle = eSkipTime;

Is this correct?

Yours.
Jay.

Not to worry. It appears that I was right because it works.

Sorry to say this... but...
I have been working with 3.4 for the past week now and just don't like it. :(
I have gone back to 3.2.1 (Draconian) and feel as if I have just been reunited with an old friend. ;-D

Ok.
Forget what I said above, everything was just wrong with the world this morning and I decided to take it out on AGS. (roll)
3.4 is NOT horrible I just find it rather difficult to work with, at the moment.
I have decided to go back to 3.2.1.(Drac) though for now (sorry I just like it.) ;-D
I will check 3.4 out when it's officially released though.

Yours.
Jay. 

Jay, what was it about 3.4 that made it so unusable for you? Did you experience actual errors?

There are definitely breaking changes, but the current version should be pretty stable by now in terms of actual bugs.

---

In an unrelated note, I've actually added compile errors to the DataFileWriter class (the new game compiler) for the instances where I had inadvertently removed them (too many dialogs, too many inventory items, etc.). I'm reinstalling VS 2008 right now (formatted the computer recently) so that I can rebuild and make sure that I haven't mucked anything up, then I'll put in a pull request for it.

Hi Monkey_05_06

My chief gripes with AGS 3.4 are as follows.

1. I find the Win setup to be an odd beast. Games that run in 640x480 that used to run full screen on my monitor now do not, unless I stretch the screen which has strange effects on the graphics.
   Also trying other resolutions and settings cause my game to look fuzzy. (This was the main reason I reverted back to Draconian).
2. The white screen when scripting really draws on my eyes and I find properly indenting my script to be awkward as there is now no border, after the line number, as a guide.
   (The second reason I reverted back to Draconian). Also when trying to edit script I keep, for some reason, clicking those bloody minus signs, condensing my script.
3. As I mentioned to CrimsonWizard, a short time ago, there are still some sound issues. The sound panning and sound with scaling doesn't work.
4. Two separate windows to click between for properties and events. Is this really necessary or just a gimmick. (I found I kept wondering where things had gone until I remembered I had to click one pane
   or the other.)

Apart from these gripes I did not actually receive any error messages. ;-D
I know that you may find these things, I have mentioned, trivial but things that were working fine before are being overcomplicated now on 3.4. (Just my opinion though.) ;)

Yours.
Jay.

Quote from: RetroJay on Wed 11/03/2015 19:49:55
...
4. Two separate windows to click between for properties and events. Is this really necessary or just a gimmick. (I found I kept wondering where things had gone until I remembered I had to click one pane
   or the other.)

Things like these seem 'trivial' but can have a huge effect on workflow. I often do not have a mouse, but have to use a trackpad or touch screen and so this is a pretty big deal for me, too!

My question is, how far off is 3.4 official? Is it far enough away to consider suggestions for layout modifications and more keybinds for keyboard-centric developers? Or is the plan to push 3.4 out as soon as current features are ironed out?

I don't think layout modifications would be off-the-table yet, so long as there's no need to introduce whole new classes or libraries.

The issue of the Events pane being "hidden" inside the Properties pane is something that is (in my experience, anyway) extremely common. The only IDEs I've really used for any type of GUI development have been Visual Studio (C++ and C#) and Eclipse (Java) (Edit: That is, the official WindowBuilder plugin for Eclipse). Both of these IDEs have the same behavior, where there is a Properties pane with a button you click to access the Events for the selected item.

It may be possible to allow dragging that out to a separate window/tab. Probably the best person to ask about that would be tzachs. But in any case, I don't really find it "gimmicky" so much as I find it familiar...

Also, contrary to what RetroJay's post implies, this is not a new part of the 3.4 UI. I'm almost positive it's been like this since the introduction of the C#-based editor, if not before.

Hi,

I was pointed towards this thread by Crimson Wizard (thanks!) so I would like to add something to this discussion.

See: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51997.0 for the background.

I am playing with the alpha version now, in Full HD, and then I noticed scaling artefacts etc. My "simple" solution would be to set the game resulution to 1920 x 1020 instead of 1920 x 1080 to avoid scaling in windowed mode. The screens becomes scrollable because I am still working with 1920x1080 images, but that actually works quite nice!

So my suggestion would be that some kind of setting should be there, for which you can say if a room must be scaled, or scrollable in case it doesn't fit the actually game resolution.

I have a 2 weeks vacations starting from the next week, during which I will be less on forums, but I hope to finally work on the mouse sensitivity issue again, and maybe some other things.

Regarding the further development; I must accept that as my own organizational failure again, that the 3.4.0 is taking a little long already (and getting little big), and there certainly were things that could be released earlier. Additional problem is that we have particular features introduced, but not complete (they either have annoying bugs, or simply not working as they should in all aspects yet).

Therefore, the decision I am proposing is this:

1. We slow down on adding features to 3.4.0 now; preliminary deciding which extra features it still might need. By features I mean completely new stuff, not fixes of something that does not work well (enough) - that's a separate question. We should not go too far with these. I will note the ones I believe should be added, or at least considered, below.

2. To improve the usability of 3.4.0, and therefore let people use new wanted features with less fear, we might focus on fixing the worst of the known problems first. I suggest developers should scan through the changes they were working on in the past time and see if anything requires fixing. I will make couple of notes regarding these below too.

3. When considering on adding a feature or a fix, we need to examine whether it could be added on top of 3.3 branch instead.
It is difficult to make a strict rule here, but I think that it may go to the next 3.3.* release if:
a) it does not depend on any of the changes made in 3.4.0;
b) it does not belong to same distinct group of features as introduced in 3.4.0 (like the lots of new script commands made by Gurok);
c) it does not require a big rewrite of the existing code, - this is something we do in 3.4.0.
d) critical fixes (program crashes etc).

4. This might happen that someone would like to start working on a new feature, and find him/her-self having progress, but the feature may be too large or taking too long to add into 3.4.0 (since the proposal is to start "freezing" it) - in such case we may create a next development branch for 3.5, and even make an alpha release, if some users will be wanting to have them.
But that is a possibility; I would prefer we finish what we started first.


The features I would like to still put into 3.4 branch are:
+ Mouse sensitivity (I really hope to finish this);
+ Draconian features (http://www.adventuregamestudio.co.uk/forums/index.php?topic=44502.msg636515126#msg636515126);
+ Fully working User managed structs (they would put AGS script up on a completely new level).
+ Sprite cache limit (was bugging several users in the past already).

Most annoying problems to fix:
+ Well, first of all is a new game compilation system (multiplatform), which has number of seemingly non-critical, but pretty irritating glitches (dedicated thread here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51289.0);
+ Some bugs in display resolution init were reported, I'd need to look into them.


A special note regarding ports (especially mobile ones and OSX, because Linux is more or less stable now).
I was asked about them number of times, and I must say this.
Unfortunately, I have a little knowledge of them, and did not have a chance to study their work. This will be impossible for me to do anything without learning how they work, which requires time, which I do not have much at the moment. Realistically, I would not be able to do anything here, at least not before we make a first stable 3.4.0 version.
That would be very fortunate if someone could dedicate him/her-self as a port maintainer to solve many questions asked in related threads and provide new builds regularly. OSX port requires special treatment, which I would not discuss right here (there is a lot to say, and I would like to speak only to someone who is ready to work on it).

Same with various documentation, manual etc, I probably won't be able to address these issues until stable 3.4. As you may see, my time I can dedicate to AGS is limited, and I find it very difficult to switch between tasks all time.

I will spend some time reorganizing issues in the tracker now.
There is a useful option to display issues assigned for particular milestone. To access it go to "Bug and Suggestion Tracker" -> choose your project -> click on "Roadmap" button at the header.
You will see a list of available versions. Find the one you are interested with (e.g. AGS 3.3.5 or AGS 3.4.0) and click on the link. You shall see a filtered list of issues.

There is a bit of mess there with some obsolete versions right now, but I am going to clean that up.

By the way, regarding rewriting the setup program in a cross-platform way which was discussed some time ago.

I was going to write a simple application using a basic GUI lib (like FLTK, IIRC). The main reason I halted this "project" was a lack of free time, which I'd rather dedicated to actual engine improvement and release of the custom resolutions version.
However, there were also two bothering problems which would appear for any stand-alone application.

1. How to make setup program compatible with the engine, in the sense that it should display graphic modes and filters, supported by the engine?
Of course, it is possible to hard-code everything inside such application, but then we would need to update it whenever engine gains or looses a feature. Furthermore, we would have to resolve situations with backwards compatibility (like, what would happen if we put a newer setup with an older game)?
Ideally, setup should inquire engine about features it supports somehow. I was thinking even about such things as making them converse via a pipe, or temporary file on disk, or even make the engine output something int stdout.

Or moving particular parts of the engine into DLL to let setup load it and call its functions.

Maybe, I was not seeing some prettier solution here.

2. How to make setup program know which game were are configuring? Also, if the setup program has "Save & Run" button, how to make it run the program we want? What if there are several games in a folder? (not usual with AGS games, but still).


I was thinking this situation over recently, and suddenly realized that there is another option, besides stand-alone app: a plugin interface.

What if there were a plugin interface for setup dialog made into DLL?
a) the engine could run such setup dialog from itself when it wants (e.g. if the default config file is not found).
b) the engine could easily pass any information to such plugin (game title and parameters, supported gfx modes, featured filters, etc).
c) the engine could even pass some of the game resources (!) - such as sprites or audio - to setup program.
d) standartized API would make it simplier to write custom compatible and replaceable setup apps for game developers and other parties.

What do you think about this?


E: Cons?
a) you won't be able to run a setup without an engine present. (But would you need to?)
b) engine has to know how this setup dll is called. Or, search for any dll which supports plugin interface.
c) you can't use this setup-DLL with games made with older engine, obviously.

Running the engine to get information from it sounds good.
An alternative would be to supply a number of text files (or so) that have the information, but those can get lost, contain wrong information, etc.

As for cross-platform, plugin is also a good form of running the engine, I think. DLL won't fly cross-platform, Linux has .so files instead, no idea what android or mac uses. Depending on the meaning of "cross-platform" things may get a bit ugly.

Another form could be to add a few command-line flags to the engine, and have it spit out the relevant information. You see this a lot with *config programs for libraries.
$ sdl2-config -h
Usage: /usr/bin/sdl2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]

$ sdl2-config --libs
-lSDL2 -lpthread

$ sdl2-config --cflags
-I/usr/include/SDL2 -D_REENTRANTIn this case 'sdl2-config' is a script generated while building the sdl2 library. You can ask it for compiler and install settings, so a program needing libsdl2 can be configured with the correct parameters and paths for the system.
Obviously, you don't need to use a separate program, you can use the program itself too (libraries don't have an executable, so generating a script is a logicial next step). Also, since you get text in return, you can get any information you need, you just need to parse the returned text. As you control the text output as well, it's easy to pick a simple-to-parse format.

Quote from: Alberth on Sun 02/08/2015 18:07:51
As for cross-platform, plugin is also a good form of running the engine, I think. DLL won't fly cross-platform, Linux has .so files instead, no idea what android or mac uses. Depending on the meaning of "cross-platform" things may get a bit ugly.

By DLL I meant any dynamically linked object, not only Windows DLL. We have plugins made for Linux too, using same code, but ofcourse you need to supply open source code for those who would like to build themselves.
Not sure about mobile platforms though, they might have some format too, but they also may impose extra restrictions to program content. Anyway, they are less concern, because they already have launchers which set games up, and the resolution settings are mostly automated.

Sounds good to me.