AGS 3.3.x/3.4.0.0 Developer Discussion

Started by Gurok, Sun 09/02/2014 08:45:13

Previous topic - Next topic

monkey0506

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

Crimson Wizard

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.

monkey0506

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

Sslaxx

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?
Stuart "Sslaxx" Moore.

Crimson Wizard

#164
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.

monkey0506

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.

Gurok

#166
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
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

#167
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.

Crimson Wizard

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. Of course, constructive critisism on code is welcome too.

Crimson Wizard

#169
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.

Calin Leafshade

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.

Code: c#

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;
    }
}

Crimson Wizard

#171
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#

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.

Crimson Wizard

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.

Crimson Wizard

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.

Gurok

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.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

#175
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:

Code: csharp

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

Gurok

Hey CW, just wanted to say thanks for eliminating that UpdateCPPVersion utility. Building is so much easier now without it!
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

MOAR AGS MADDNESS INCOMING!!!

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

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

Gurok

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.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

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.

SMF spam blocked by CleanTalk